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

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 UTC