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

Travis Snoozy 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 existing If-* options don't matter to this discussion.  Some
servers ignore them all anyway.

> -- the client still has to be able to
> detect whether the server actually supports pipelining,

Unfortunately there isn't anyway to do this reliably, because of
pipelining bugs in the wild.

> 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?).

Out of order responses are an improvment, but they are just another
level of hack.  Large reponses still block small responses, sometimes
for a very long time.  When considering out of order responses for
HTTP, maybe alternative multiplex/transport mechanisms like BEEP or
SCTP are worth looking at.

I agree totally with your point, that _merely_ adding new headers
isn't enough to make reliable pipelining of any kind from general
clients to existing servers in the wild.

That's no reason to assume it's impossible to do.  Only that it would
have to be more complicated than simply adding a header, if it's
possible at all.

But first, before thinking about nitty gritty details, there would
need to be a higher level interest in the ideas of chained
conditionals, out of order responses, multiplexing, streaming,
predicated caching and leasing, or whatever people are interested in...

If we have the high level interest, we can look at ways to implement
it them on the wire and try to find something which is backward
compatible, as a real world version even if it has to be ugly, and an
ideal version, perhaps to be deployed in 2022 by phasing out the
hacks.

-- Jamie

Received on Friday, 7 September 2007 18:36:12 UTC