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

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Oct 2008 17:36:32 +1000

I puzzled over your answer for a little while, Roy. I'm not sure I'd  
say it in the same way, but I agree with you, because the If-Match  
header is being badly misused here.

E.g.,

> Client sends initial handshake:
>
> POST /upload HTTP/1.1
> Host: example.com
> Content-Length: 0
> Content-Range: bytes */100
> Server assigns ETag:
>
> HTTP/1.1 308 Resume Incomplete
> ETag: "vEpr6barcD"
> Content-Length: 0
> Client initiates upload:
>
> POST /upload HTTP/1.1
> Host: example.com
> If-Match: "vEpr6barcD"
> Content-Length: 100
> Content-Range: 0-99/100
>
> [bytes 0-99]

Here, If-Match is being used to declare which pseudo-resource is being  
uploaded to; its original/actual semantics are completely lost.

So, bringing it back to HTTPbis, how does the below affect issue

On 20/09/2008, at 2:01 AM, Roy T. Fielding wrote:

> On Sep 19, 2008, at 7:28 AM, Charles Fry wrote:
>> A few more thoughts on URLs and ETags:
>>
>> - While it isn't clear in the examples on the wiki page, the initial
>> handshake is optional. In other words, it represents one extreme end
>> of the protocol, but the primitive requirement is that unique
>> identifier (whether URL or ETag) be obtained. This could very well be
>> present in an HTML page, for example, allowing a resumable upload
>> without the initial handshake.
>>
>> - Regarding ETags vs. URLs, one point of reference for me is CGI
>> scripts. A single CGI script running behind a fixed URL should (in my
>> mind) be able to perform a resumable upload, but this would require a
>> unique identification mechanism other than the URL.
>
> That isn't relevant -- any CGI script (and just about any part of a
> server's URI space) can be overlapped as many times as you want.
> In any case, ETag is not a unique identifier.
>
> I already explained how to do this functionality in
> <mid:[email-masked]> on Apr 4.
>
> The ETag examples you provide don't make any sense.  Etags only
> have meaning within the scope of a resource's current representations.
> If you are posting to a service that has no corresponding resource
> mapping, the etag in response must correspond to the etag that you
> would have received if the request were a GET on that service.
> In essence, this allows a service to be versioned, though such
> interfaces are not typically used on the Web because we prefer to
> use backwards compatible services rather than strict version coupling.
>
> So, the short answer is that only the URI solution fits within
> the current web architecture.
>
> ....Roy

--
Mark Nottingham       [email-masked]