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 PROTECTED]> 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 PROTECTED]
