Catching up a bit late...
On 29/08/2008, at 11:13 PM, Julian Reschke wrote:
The problem in offering widely differing ways to do the same thing
is that
at least in the beginning, clients and servers would need to
implement all
of them in order to achieve some kind of interoperability. It
would be
great if this could be avoided.
Good point. We'll definitely consider that.
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).
It would be interesting to hear why you think these additional
parts are
needed.
Content-Range request header: used to specify which byte range is
being sent. Roy's proposal simply suggested appending bytes, but that
leads to requests which are non-idempotent.
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.
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.
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...
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).
Cheers,
--
Mark Nottingham [EMAIL PROTECTED]
