W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: PROPOSAL: i99 Pipelining Problems

From: Jamie Lokier <jamie@shareable.org>
Date: Mon, 7 Apr 2008 13:02:50 +0100
To: Henrik Nordstrom <henrik@henriknordstrom.net>
Cc: Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20080407120250.GB29219@shareable.org>

Henrik Nordstrom wrote:
> I prefer not adding this to the specs as it reduces the push on such
> vendors to get their software fixed to support pipelining, opening up a
> for dialogue like the following
> 
> Comments aiding implementers in how to deal with the current mess of
> clearly broken and non-compliant implementations is best placed in a
> separate informal document outside the standard documenting known bugs
> and how to deal with them.

I agree, and even better if it's written as a "Hall Of Shame Of Low
Quality Implementations".

 The focus in the standard text itself should
> be longterm interoperability. These implementations is very likely to
> decline over time, and having such comments in the standard text itself
> only adds confusion.

I agree with this too.

I notice that there are some things mentioned which are like this
already, though: the recommendation to accept LF without CR for
compatibility with some (unspecified) old agents, and that some old
clients follow the request entity with a blank line.

Imho, such notes are extremely useful for new implementors, but I'd be
very happy if they were maintained in a separate document of 'Hall of
Shame: Implementation guidelines for practical compatibility with
non-complient but widely deployed implementations'.

Like the one for TCP.

> I would be very glad the day the major browsers started
> to actually alert the user when a broken server is detected instead of
> just silently work around it, placing some pressure on getting servers
> fixed.

The ideal evolution there might be mechanisms to detect broken
servers, alert the user, but still successfully show the right
content, for a few years.

That will be a lot easier to implement in browsers if there's a
collective document of shared knowledge of what specific types of
broken behaviour to look for.  I find that knowledge is currently far
too embedded in the source code (and only there) of major browsers -
and it's never clear which things are workarounds for servers, and
which are merely implementation bugs or laxity in the browsers
themselves.

-- Jamie
Received on Monday, 7 April 2008 12:03:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:46 GMT