[jerf]

I agree with you for the most part. Like I said, I consider it too dangerous to use, not that it's somehow impossible. But the reason I consider it too dangerous isn't that it's a Violation of the Holy Spec... everything and everyone violates the spec, to a first approximation. The problem is that all the libraries in the world and middleboxes and everything else violate the spec in different ways, and allow/enable/afford their own set of violations that do not match.

If you spec an HTTP API as having a GET with a body ("because otherwise the query string will be too long" or something), I can virtually guarantee you that as soon as it is even slightly popular you're going to get "But I'm using this library over here in some language you've barely heard of and its author thinks GET can't have a body so it won't send it to you, plz hlp".

I wouldn't consider it safe to deliberately use in an API. Similarly, I once accidentally sent a real reply as a 404 response (just a plain ol' bug), and while I did of course fix it quickly in my API, the user on the other end didn't have a good option for just ignoring it and moving on in the meantime. Their HTTP library got really feisty about using the body of a 404 ... I think it was something like, you could read it as a bag of bytes but all the clever "let's automatically JSONify this" and stuff functionality in their framework wouldn't fire on a 404. This is why I mentioned that one. It is a bad idea to treat the content of a 404 response as anything other than an advisory response to a human, and even that has some funny characteristics based on browser screwiness over the years.

There's definitely violations of the spec safer to specify, and violations less safe to specify; they're not all created equal.