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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 17 Sep 2008 10:11:34 +1000
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>
Message-Id: <319E150D-D826-43F8-AB7B-67643E3E375F@mnot.net>
To: Charles Fry <fry@google.com>

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  

> 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.


Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 17 September 2008 00:12:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC