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