On Mar 3, 2008, at 10:15 AM, Roy T. Fielding wrote:
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? 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. 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. If the problem solved by idempotency requirements only happens when there are failed connections, is it worth solving? Or is there a requirement for recovering from failed connections which clients would be capable of following -- such as retrying requests in order if it retries any? Lisa |