On Tue, Sep 16, 2008 at 9:46 AM, Jamie Lokier <[EMAIL PROTECTED]> wrote:
> Brian McBarron wrote: > > On Tue, Sep 16, 2008 at 9:19 AM, Jamie Lokier <[EMAIL PROTECTED]> > 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.
