W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

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

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Thu, 2 Oct 2008 17:36:32 +1000
Cc: Charles Fry <fry@google.com>, Jamie Lokier <jamie@shareable.org>, Brian McBarron <bpm@google.com>, <gears-eng@googlegroups.com>, Julian Reschke <julian.reschke@gmx.de>, Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <2D79C110-D6B8-45C2-8B66-7E518D38071F@yahoo-inc.com>
To: "Roy T. Fielding" <fielding@gbiv.com>

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:3173C7D0-7078-480E-9B99-E174AD2001DA@gbiv.com> 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       mnot@yahoo-inc.com
Received on Thursday, 2 October 2008 07:37:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:56 GMT