- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 17 Sep 2008 10:11:34 +1000
- To: Charles Fry <fry@google.com>
- Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "Julian Reschke" <julian.reschke@gmx.de>, gears-eng@googlegroups.com, "Alex Rousskov" <rousskov@measurement-factory.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
On 16/09/2008, at 9:22 PM, Charles Fry wrote: > >>>> Back to your comment; >>>>> >>>>> 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. >>>> >>>> I don't know that I agree; with PUT, it's very natural to use >>>> ETags (you >>>> avoid creating the temporary resource, and have the option of >>>> 409'ing any >>>> concurrent PUTs after the first), whereas with POST, you're just >>> >>> That assumes that PUT with Content-Range can be used today, which >>> really >>> isn't the case, unless the client can be confident that the server >>> actually >>> understands PUT with ranges. >> >> That seems to be a problem with all the approaches on the table, >> according >> to the flows in the current document. By the letter of the law, if >> the >> server doesn't understand a Content-* header on a PUT request, it >> should >> refuse it, but we already have an open issue or two (#79, #102) on >> that... > > So clearly a client should not start sending resumable PUT/POST > requests to a server that doesn't support them. The HTTP/1.0 version > of the protocol is _not_ self-discoverable. The only way we propose > self-discoverability is in the form of 103 responses sent by the > server to HTTP/1.1 compliant clients (through HTTP/1.1 compliant > proxies). Well, HTTP/1.0 doesn't define PUT; it first shows up in RFC2068, which says: > the recipient of the entity MUST NOT ignore any Content-* (e.g. > Content-Range) headers that it does not understand or implement and > MUST return a 501 (Not Implemented) response in such cases. (as 2616 does). So, in theory you can PUT with Content-Range and know that if the server doesn't support resumable requests, you'll get a 501. In practice, of course, may be a completely different kettle of fish. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 17 September 2008 00:12:17 UTC