- From: Jim Gettys <jg@freedesktop.org>
- Date: Mon, 26 Sep 2011 13:38:20 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Noah Mendelsohn <nrm@arcanedomain.com>, Jonathan Rees <jar@creativecommons.org>, Jeni Tennison <jeni@jenitennison.com>, "www-tag@w3.org List" <www-tag@w3.org>
On 09/26/2011 01:28 PM, Julian Reschke wrote:
> On 2011-09-26 19:04, Jim Gettys wrote:
>> On 09/26/2011 11:46 AM, Julian Reschke wrote:
>>> On 2011-09-26 15:25, Jim Gettys wrote:
>>>> ...
>>>> o lack of request #'s in responses, making out of order delivery
>>>> problematic.
>>>> ...
>>>
>>> Clarifying: server and intermediates are not supposed to re-order
>>> responses.
>>>
>>> So is this about being able to better work around this kind of
>>> breakage?
>>>
>> Not just the breakage: given what web sites have evolved into, I can see
>> what caused the breakage. Getting things back into order (given a
>> complex back end) is hard.
>>
>> And the server may have better information than the client what matters
>> to get first, conceivably.
>
> Me confused :-)
>
> Out-of-order delivery is not allowed by RFC 2616 -- we should be clear
> about things that would be nice-to-have for debugging, and things that
> maybe should have been defined differently...
>
By not having defined out of order delivery in 2068/2616 we set
ourselves up for many of the problems that we now face in HTTP/1.1
deployment, since the realities of many big web sites make it hard to
preserve ordering.
Whether this should be fixed at this very late date given eventual
possible replacement of "classic" HTTP, is a different discussion.
That I consider it a bug in the protocol, is not worth discussing.
- Jim
- Jim
Received on Monday, 26 September 2011 17:39:00 UTC