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

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

> BTW, we should really be talking about an Internet-Draft at this point,
> rather than a wiki page. Google guys, when will that happen?

At a high-level we'd been hoping to at least get some high-level
community feedback confirming that we are ready to move onto that
step. If there is agreement that it is time to proceed there then
we'll work on putting one together.

And thanks to all for all of the feedback and discussion.

Charles

Received on Tuesday, 16 September 2008 11:23:29 UTC