Mark Nottingham wrote:
...
I think the biggest simplification would be to select either the ETag
based approach or the URI-based approach (where I think the latter
works better).
Big +1. Simpifying is a good thing. Don't try to keep *everybody* happy.
Although I started this e-mail with no real preference, I'm leaning
towards the ETag-based approach, for the reasons below (although there
may be a way to address them).
Looking at your feedback I realize that what I really was thinking of
was an URI-based approach *with* (strong) ETags.
...
It depends. If the "append" operation always uses POST/If-Match, then
each of these requests is idempotent (it will either succeed, or the
server will reject it because the ETag isn't current anymore).
...but that's if you're using an ETag. My reading was that ETags vs.
different URLs would be an either/or thing in this proposal... If one of
them is picked and the other discarded, it would be easier to make a
judgement about this.
Right. See above -- ETags should be used anyway (no matter whether
special URIs are used or not).
the precedent of byte-range GETs. If a byte-range POST is being
performed, then by all means let's specify which range of bytes are
being sent!
I think sending the Content-Range header is harmless, but not required
for the whole thing to work.
If it's being done across multiple URIs, you're really bending if not
breaking the semantics of Content-Range.
Maybe I wasn't clear what I was proposing: each resumable transfer would
get a specific URI, and the various stages of that transfer would be
identified by a specific ETag. Thinking of it, in this case the ETag
*could* be built based on the number of bytes and the digest of bytes
received.
As far as I can tell, if you use the ETag based approach, and multiple
clients try to post to the same collection (POST URI), then you'll
have to disambiguate the requests. That problem would go away if each
of them would use a different URL.
I read the doc as saying that the server would provide unique ETags
somehow...
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.
One other issue; caches use a set of rules against requests to determine
when to invalidate their entries (section 13.10); generally, it's
desirable to do so when the response is received (i.e., when the request
body is stored/processed on the origin server). The ETag-based approach
will work nicely with this, but the URL-based one will not; the request
URI will be invalidated when the request has started -- but potentially
*not* finished -- on the origin server.
Also, I haven't thought through it completely, but it seems like it
would be compelling to implement this feature in an intermediary (i.e.,
an accelerator in front of your servers). Using the ETag approach would
avoid having to worry about coordinating URI space between the
intermediary and origin server, although there are probably other issues
to consider (e.g., doing the initial handshake).
That's an interesting idea, but again, using the same URI to handle
multiple transfers at once doesn't feel right to me...
BR, Julian
