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
