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

Catching up a bit late...

On 29/08/2008, at 11:13 PM, Julian Reschke wrote:
>>>
>>> The problem in offering widely differing ways to do the same thing  
>>> is that
>>> at least in the beginning, clients and servers would need to  
>>> implement all
>>> of them in order to achieve some kind of interoperability.  It  
>>> would be
>>> great if this could be avoided.
>> Good point. We'll definitely consider that.
>
> I think the biggest simplification would be to select either the  
> ETag based approach or the URI-based approach (where I think the  
> latter works better).

Big +1. Simpifying is a good thing. Don't try to keep *everybody* happy.

Although I started this e-mail with no real preference, I'm leaning  
towards the ETag-based approach, for the reasons below (although there  
may be a way to address them).


>>> It would be interesting to hear why you think these additional  
>>> parts are
>>> needed.
>> Content-Range request header: used to specify which byte range is
>> being sent. Roy's proposal simply suggested appending bytes, but that
>> leads to requests which are non-idempotent.
>
> It depends. If the "append" operation always uses POST/If-Match,  
> then each of these requests is idempotent (it will either succeed,  
> or the server will reject it because the ETag isn't current anymore).

...but that's if you're using an ETag. My reading was that ETags vs.  
different URLs would be an either/or thing in this proposal... If one  
of them is picked and the other discarded, it would be easier to make  
a judgement about this.


>> the precedent of byte-range GETs. If a byte-range POST is being
>> performed, then by all means let's specify which range of bytes are
>> being sent!
>
> I think sending the Content-Range header is harmless, but not  
> required for the whole thing to work.

If it's being done across multiple URIs, you're really bending if not  
breaking the semantics of Content-Range.


> As far as I can tell, if you use the ETag based approach, and  
> multiple clients try to post to the same collection (POST URI), then  
> you'll have to disambiguate the requests. That problem would go away  
> if each of them would use a different URL.

I read the doc as saying that the server would provide unique ETags  
somehow...


One other issue; caches use a set of rules against requests to  
determine when to invalidate their entries (section 13.10); generally,  
it's desirable to do so when the response is received (i.e., when the  
request body is stored/processed on the origin server). The ETag-based  
approach will work nicely with this, but the URL-based one will not;  
the request URI will be invalidated when the request has started --  
but potentially *not* finished -- on the origin server.

Also, I haven't thought through it completely, but it seems like it  
would be compelling to implement this feature in an intermediary  
(i.e., an accelerator in front of your servers). Using the ETag  
approach would avoid having to worry about coordinating URI space  
between the intermediary and origin server, although there are  
probably other issues to consider (e.g., doing the initial handshake).

Cheers,


--
Mark Nottingham       mnot@yahoo-inc.com

Received on Friday, 12 September 2008 04:26:29 UTC