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

Mark Nottingham wrote:
> ...
>> 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).

Looking at your feedback I realize that what I really was thinking of 
was an URI-based approach *with* (strong) ETags.

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

Right. See above -- ETags should be used anyway (no matter whether 
special URIs are used or not).

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

Maybe I wasn't clear what I was proposing: each resumable transfer would 
get a specific URI, and the various stages of that transfer would be 
identified by a specific ETag. Thinking of it, in this case the ETag 
*could* be built based on the number of bytes and the digest of bytes 
received.

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

Disambiguating by ETag probably would work, but that doesn't feel right 
to me. If multiple resumable transfers can be in progress at the same 
point of time, then this really sounds like multiple resources (thus 
multiple URIs), not multiple variants of the same resource to me.

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

That's an interesting idea, but again, using the same URI to handle 
multiple transfers at once doesn't feel right to me...

BR, Julian

Received on Friday, 12 September 2008 07:26:34 UTC