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

On fre, 2007-09-07 at 19:35 +0100, Jamie Lokier wrote:

> The existing If-* options don't matter to this discussion.  Some
> servers ignore them all anyway.

Not sure how that's relevant here.. Capabilities will never be better
than both endpoints no matter how much the protocol is extended.

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

Yes, just as there will be plenty of bugs in the implementation of 209..

> Out of order responses are an improvment, but they are just another
> level of hack.

And a bad one..

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

Yes. SCTP looks quite interesting as a transport for HTTP.

It's also worth noting that when using SCTP the whole concept of
pipelining and persistent connections pretty much goes away for free,
and all you need to continue worring about is non-idempotence and
request reordering..

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

The only reliable method for that is to actively work on getting the
server bugs fixed and broken equipment phased out, or to abandon
pipelining and switch to SCTP or other transports more suited for the
purpose.

There is a number of technical problems with HTTP pipelining, nearly all
from the mixing of transport and protocol where.

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

chained conditionals using predicted conditions without using ETag &
If-(None-)Match etc will be very hard to make reliable within HTTP/1.x. 

The existing conditionals work pretty well, but requires responses to
any modifications to reach the client before it can continue the chain..

Regards
Henrik