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: Brian McBarron <bpm@google.com>
Date: Tue, 16 Sep 2008 09:26:58 -0400
Message-ID: <f478254d0809160626w590990cdg7f56dd6a67ad23cc@mail.gmail.com>
To: gears-eng@googlegroups.com
Cc: "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>
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.
Received on Tuesday, 16 September 2008 13:27:46 GMT

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