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

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

Received on Wednesday, 17 September 2008 00:12:17 UTC