- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 16 Sep 2008 10:11:54 +0200
- 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 UTC