The W3C? They don't publish HTTP specifications. That's down to the Internet Engineering Task Force (IETF) through the Request For Comments (RFC) document series, though some of the same people are involved. The W3C do have links and copies of some of the relevant RFCs, though.Originally Posted by blm126
I don't know of any such lists, but HTTP is vast. Moreover, it's a network protocol, so it's not just browsers that are significant: there may be any number of intermediate HTTP client/servers along a particular route, acting as proxies or caches, and their behaviour is important, too. I'd be more interested to know about those, and if they're that (or at all) prevelant.but I'm looking for a list of what different browsers support.
It might be possible to check "manually" using OPTION and TRACE requests, and the Max-Forwards header in a similar fashion to trace route programs.
In all, though, client behaviour is reasonably good. There are some issues with caching (some of which can be read about in RFC 3143), redirection (see the link to Alan Flavell's article in a previous post), and Content-Type header handling (notably that some browsers try to second-guess the value), but following the specification unconditionally (see the definition in 1.2 Requirements in RFC 2616) should help avoid a lot of problems.
Of all browsers, I should think that MSIE is the most badly behaved, so if you get something behaving properly with it, you shouldn't have trouble elsewhere.
If you do, or plan to control server behaviour with server-side languages, then in my opinion, knowledge of HTTP (preferably both 1.0 [RFC 1945] and 1.1) is a must. Ignorance of it can mean that you cause the server to behave badly. It's also the cause of programming by mystical incantation: people not understanding how things work, so they try all manner of convoluted schemes in an attempt to hack out the desired behaviour.I have never really spent the time to learn that much about http,
I don't remember how well-supported 205 is, but you should be careful with both: when a user submits a form (the most likely time you'd use either in a response), it may not be obvious to them that the submission succeeded as nothing visual (or at least very little) will change. However, 204 is useful with back-end code (including AJAX) to indicate success when there's no entity to return.... I see a lot of interesting things you can do with it.For example the 204 No Content and 205 Reset Contents status codes look useful.
I know you do. It was some general musing on my part (though I'm sure I've written the same previously).Originally Posted by Twey