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

On Fri, 7 Sep 2007 12:14:51 +0100, Jamie Lokier <jamie@shareable.org>
wrote:

<snip>
> Currently, a general purpose client has to go through complicated
> heuristic contortions to decide when it is safe to pipeline requests -
> and those heuristics are not completely reliable.
> 
> If later pipelined requests were sure to abort, with no side effects,
> when an earlier request fails, or is more than a certain size, or is
> delayed, or whatever (choose your condition), then there would be more
> cases when it's safe for a client to send pipelined requests
> speculatively, without fore-knowledge of the behaviour of each
> request.
<snip>


Section 9.3 outlines when requests become a conditional GET:

The semantics of the GET method change to a "conditional GET" if the
request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field.


As you can see, it's not very extensible. Without a version bump, or
some additional detection mechanism, adding new and more powerful If-*
options doesn't solve anything -- the client still has to be able to
detect whether the server actually supports pipelining, whether it
implements the semantics of the new conditions, and if it supports them
correctly. It's entirely possible for a server with crummy pipelining
to implement new If-* header support either with buginess matching
their pipelining implementation, or (depending on the If-*) correctly
for non-pipelined requests, but without changing the pipelining code to
do the "right thing" in chained scenarios (out-of-order responses,
anyone?).


-- 
Travis

Received on Friday, 7 September 2007 17:40:01 UTC