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

On Tue, Sep 16, 2008 at 9:46 AM, Jamie Lokier <jamie@shareable.org> wrote:

> 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.
>

Requiring a header-inspecting load balancer and/or implementing a
multi-layer serving architecture seems like a steep cost to get into this
protocol.  Especially when explicit URI redirection would solve the issue
for no added cost.