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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 16 Sep 2008 10:11:54 +0200
Message-ID: <48CF6A4A.1040400@gmx.de>
To: Mark Nottingham <mnot@yahoo-inc.com>
CC: Charles Fry <fry@google.com>, gears-eng@googlegroups.com, Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>

Mark Nottingham wrote:
> ...
>> Well, not entirely.
>>
>> Let's say you've got three concurrent resumable transfers started to 
>> /a, and the server has assigned the etags "C1-1", "C2-1" and "C3-1" to 
>> the three clients.
>>
>> Client 1 starts its upload:
>>
>> REQ: POST /a
>> REQ: If-Match: "C1-1"
>> REQ: Content-Range: 0-50/100
>> REQ: [bytes]
>> RES: 200 OK
>> RES: ETag: "C1-2"
>>
>> ...what I'm concerned if is that we're essentially introduce 
>> ETag-based variant-selection here.
>>
>> So what do these ETags represent in requests *other* than resumable 
>> uploads, such as in:
>>
>> REQ: GET/a
>> REQ: If-Match: "C1-1"
>>
>> ?
>>
>> Will it have an effect?
>>
>> So just avoiding new URIs may look simpler first, but it also requires 
>> additional specification work.
> 
> It will require additional spec work if this use of ETags is 
> incompatible with existing ones. If it is, they shouldn't be used for 
> this purpose at all, but I don't *think* they are (happy to be proven 
> wrong, as always).
> 
> I.e., yes, if-match will work as specified; what else needs to be said?

OK, let's rephrase: what I'm concerned with is this:

- most of the time, resources that support POST for upload have a 
GETtable representation

- these representations (again, most of the time), are not those of 
previous upload, but a form, a collection listing, or both

- so the resource posted to has a very different nature from those it 
creates

- if, for GET/HEAD, the resource assigns and supports ETags, they have a 
very different purpose than those assigned for resumable uploads, and 
those will need to be distinguished upon GET -- so some If-Match headers 
will cause conneg, some won't

So my concern is that we use two different types of ETags on the same 
resource.

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

We *cou÷d' state that minting a new URI for resumable upload implies 
proper server support for PUT/Range; but of course that doesn't help 
with broken intermediaries.

 > ...

BR, Julian
Received on Tuesday, 16 September 2008 08:12:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT