W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: [gears-eng] Re: [google-gears-eng] Re: Deploying new expectation-extensions

From: Jamie Lokier <jamie@shareable.org>
Date: Tue, 16 Sep 2008 14:46:32 +0100
To: Brian McBarron <bpm@google.com>
Cc: gears-eng@googlegroups.com, Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@yahoo-inc.com>, Charles Fry <fry@google.com>, Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20080916134632.GA1628@shareable.org>

Brian McBarron wrote:
> On Tue, Sep 16, 2008 at 9:19 AM, Jamie Lokier <jamie@shareable.org> wrote:
>      Why use the Etag header for resumable POSTs?  If Etags are used (and
>      why not - it's handy not to have to carve out special URL space), I
>      still don't see any advantage to using the ETag _header_ for it in
>      resumed POSTs, as opposed to inventing a Resume-POST header.
> 
> Here are my use cases where ETags may not be sufficient, restated
> from earlier in this thread.  I'd love for someone to explain why
> these aren't issues, since I also like the ETag approach.
>
> I can imagine cases where redirection is key to efficient implementation of
> resumability.  Here are some use cases:
>
> 1) A server farm where the majority of traffic is handled by
> essentially diskless front-ends.  In order to support resumability,
> a server would need to redirect the client to a separate pool of
> servers who are provisioned to do the necessary caching.
>
> 2) A server farm where requests are load balanced across a pool of
> servers.  Even if the load-balancing mechanism implements a
> reasonable affinity mechanism, it's likely that that mechanism is
> just an approximation, and that any particular request may end up on
> a variety of machines.  I can imagine that an efficient
> implementation of resumability would be to ensure the user connects
> to the same machine, where the request may be cached on local disk.
> Therefore, the resumable URI could be the name of that machine,
> rather than the load balanced hostname.

These aren't a problem, as long as the front-end redirector is able
to select targets according to the Resumable-POST Etag as well as the URL.

If the front-end redirection is still approximate, there would need to
be back-end redirection too, or shared storage for partial uploads.
Lots of other variations are possible.  It's not hard to think of solutions.

It's probably useful to structure the Resumable-POST Etag to assist
front-end rediration,
e.g. "upload-foo-server1.example.com-54069843-50395-309534-059345".
How it's structured is entirely a server-side implementation detail
and doesn't need to be specified in an RFC.  Also it's not strictly
necessary, it just might make some implementations easier.  It could
also be concealed and/or signed cryptographically, if useful.  Or it
could just be a hash, with a few bits used to select upload server.

-- Jamie
Received on Tuesday, 16 September 2008 13:47:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT