- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Thu, 2 Oct 2008 17:36:32 +1000
- To: "Roy T. Fielding" <fielding@gbiv.com>
- 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>
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 UTC