Roy T. Fielding wrote:
+1. And in general clients need to be aware of these issues anyway, and well written ones are.On Mar 3, 2008, at 4:11 PM, Lisa Dusseault wrote:On Mar 3, 2008, at 10:15 AM, Roy T. Fielding wrote:There are no caching issues with pipelining -- only benefits. Theidempotency issue is due to error-recovery concerns when a connection is terminated, leaving the client with an unknown as to which non-repeatablerequests were received by the origin.Is this just a multiple-instance version of the same problem when a connection is terminated, leaving the client with an unknown as to whether a single non-repeatable request was received? Is anything different when handling broken connections with or without pipelining except the number of requests whose status is in doubt?Yes, same problem. To make it clear, let's just use POST as the exampleinstead of talking about idempotence (a mostly useless and confusing term). In all cases below, substituting "single POST request" results in the same issues and has the same set of solutions (mostly using out-of-band knowledge),yet we don't forbid POST. .... ===========I've never understood how a client can tell which methods are idempotent. PUT may not be idempotent on a versioning server. Side-effects are always possible. Unless I'm missing something, telling the client not to pipeline non-idempotent methods is a useless requirement.I'd call it actively harmful, given the number of times people have used it as an excuse not to implement pipelines. It should have been a simple warning to implementers.
However, this points out the weakness with "just use pipelining" -- it's simply not widely (effectively) deployed.
Also, most libraries I'm aware of provide no interface for controlling the ordering of requests -- and ordering is DEFINITELY important as soon as you start allowing modifying requests in the mix. A client that issues two XmlHttpRequest based requests, for example, cannot specify whether they are to be sent off nearly in parallel (the default behavior) or to be executed sequentially, except by waiting for the result of the first request and then issuing the second. Doing this of course completely defeats pipelining of any kind.
So, I'd say that if we had a pipelining mechanism that was (a) Widely deployed, including within browsers for AJAX apps (b) Had no confusion about idempotence(c) Provided enough control for clients to be able to "execute this in sequence"
...then I'd use pipelining in a second. However, I think that none of (a-c) are true or likely to be true in the near future.
Making a bunch of requests atomic should be totally separate from any batching mechanism (pipelining gets this right). Atomic updates put a huge burden on servers for what is often very little client convenience (since clients always have to deal with possible lost data when it's shipped back to them -- there is no reliable queue from server back to client).Is there a requirement which would make more sense? There should be no problem pipelining non-idempotent requests as long as the connection is healthy. This is effectively what BATCH proposals try to do: making a bunch of requests atomic, or requiring the server to get to the end of the request before applying multiple methods within it, effectively check that the connection remained healthy before applying the series of requests.Exactly. And once you have a BATCH defined, the next thing that is "optimized" is the parallel handling of requests within the batch ... and we are back to square one.
I'd submit that (specialized) clients likely have a better understanding of the pecularities of their requests and optimizations needed than general purpose servers. And parallel handling is already well handled by existing HTTP non-pipelined requests. If clients can choose which they want to use, they can optimize without needing to re-invent HTTP.
The batching proposals do require a 1:1 mapping of HTTP requests into representations that can be passed around. I think this requires minimal re-invention of specification. I hope it requires minimal re-implementation of servers and clients, though I don't have a proof of that yet.
John