RE: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

On fre, 2007-09-07 at 10:11 -0700, Yaron Goland wrote:
> This assumes that the client has an etag for the resource, in many of
> our use cases they will not. So the if-none-match approach will often
> fail.

THe client will have an ETag for the resource IF the server is capable
of providing one, and the client is interested in binding the requests
together.

If the client don't care, then there is no point of 209 either.. (just
have the client do a plain GET after the modification, pretty much the
same thing).

If the server don't care then consider fixing the server. Providing an
ETag for the resource is crucial in order to allow clients to build
meaningful sequences conditional requests.

PUT If-Match, only update if there hasn't been any changes. Returns the
new ETag.

GET If-Match, only get if there hasn't been any changes.

GET If-None-Match, only get if there has been changes.

Without ETag these sequences gets much harder, and ETag is already
there, make use of it.

Don't be scared off by the recent discussions about the meaning of ETag,
those discussions is only related to a couple cornercases where the
specifications is a little vague, and also WebDAV which do not fit into
the HTTP object model very well which makes things quite a bit confusing
when trying to map it to the HTTP object model..


And regarding pipelining, there is certain aspects of pipelining that
one has to accept for the lifetime of HTTP/1.x:

 - Don't pipeline non-idempotent requests unless you know exactly what
you are doing. It's very hard to know how far a pipeline got processed
in case of error.

 - Don't pipeline non-idempotent sequences of requests (i.e. a GET
followed by a DELETE of the same resource). There is no guarantee the
requests will be executed in the exact same order. Reordering of
requests may occur in hops along the HTTP forwarding path, or even in
the requested server if it's a multi-threaded server.

 - Don't pipeline when average response latency is important. A large
response will block the responses to the following requests..


Regards
Henrik