On ons, 2007-11-21 at 16:10 +0000, Geoffrey Sneddon wrote: > On 20 Nov 2007, at 21:54, Henrik Nordstrom wrote: > > > It's up to the implementer omho. Implementation detail on how to > > behave when > > seeing things outside specifications. > > I strongly disagree — as an implementer, I want to be able to > implement HTTP in such a way that it works in the real world (which, > in places, relies on totally unspecified behaviour found in browsers) > by just reading the spec. If RFC2616bis doesn't address this, other > documentation on this will likely appear scattered over the web > outwith the HTTP spec. If I cannot just implement HTTP from the spec > in such a way that is interoperable with real-world servers, then IMHO > the spec is too vague and I have to waste my time reverse-engineering > other implementations (likely still not in a way 100% interoperable > with real-world servers). The specs do not always say what you must do when someone sends you stuff which doesn't make sense or which isn't allowed to be sent. I don't think it should. It's best left to each implementer how much crap they accept as valid, or how/if they inform the user that there is crap given to them on the wire. Specs do say what is allowed, and how that is to be understood. Any glitches there is what RFC2616bis aims at correcting, plus increasing the overall readability of what is said. It's only worth considering crap when it has serious implications on security- Regards Henrik
Received on Wednesday, 21 November 2007 22:44:27 UTC