[hobohacker]

I guess I should out myself as a Chromium HTTP stack maintainer (since 2009, so this behavior predates me). One might consider me a domain expert here. I participate in IETF HTTPbis for the HTTP/2 work as the primary Chromium representative. I am not involved with the RFC 2616 revision work as that's tough, thankless work, that thank god we have Julian Reschke and Roy Fielding working on. As far as I'm concerned, I owe them a drink everytime I see them. They do an awful lot of legwork talking to various implementations and trying to build consensus on actually conforming with the standard and all its edge cases. It's really quite unfortunate to see this blog post author treat them so unfairly, although I can see how one might easily jump to his conclusion.

Now, as far as "SHOULD NOT", that's a reasonable thought for people not aware of what popular user agents currently do. The thing is, the majority of major browsers rewrite POST to GET on a 301. Here's my browser's code for it: https://code.google.com/p/chromium/codesearch#chromium/src/n.... Here's Firefox's code for it: http://mxr.mozilla.org/mozilla-central/source/netwerk/protoc.... To my knowledge, all browsers implement this behavior. We basically copied IE's behavior, because, IE did it and websites expected all user agents to do what IE did. Story of the web, sound familiar? :P

So, as you can see, Julian was merely acknowledging the pragmatic reality of the situation when he updated the httpbis specs to reflect this behavior: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1428. And this reasoning behind it is covered in the introduction to the relevant section in the httpbis docs: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-2....

"SHOULD NOT" implies that our implementations are behaving badly. Now, it's true, our implementations may not be behaving ideally from a spec cleanliness point of view, but interop trumps spec cleanliness, at least from the perspective of anyone who actually deploys real software on the internet. So it's probably best for the spec to acknowledge this and officially allow this. Specs that don't mirror reality are...probably not just useless, but actively harmful.

I hope that explains things, cheers.

[Lukasa]

You're entirely right, and it's not just browsers. Your statement about 'user agents' was the better one. Consider also curl (http://curl.haxx.se/docs/manpage.html#-L) (and presumably libcurl), Python's requests (https://github.com/kennethreitz/requests/blob/master/request...) library, Python's urllib.request (http://docs.python.org/3.3/library/urllib.request.html#urlli...) (what used to be urllib2), the list goes on. I don't believe I've ever seen a HTTP client library that doesn't do 301 method conversion.

[nemetroid]

So basically the entire premise of the article, that

> existing practice today is that 301, 303, and 307 are used correctly pretty much everywhere

is flat out wrong. I guess that's a nicer and more probable resolution than "standards people suck!".

[hmsimha]

From the rest of the article, I can only assume it means 'correctly' in the sense of the reality arrived at by both user agents and servers after years of standards-flouting, which is now 'correct' if unspecified behavior.

[lstamour]

Makes sense. Clears up the table at the end too. In reality, as with HTML5, such a change matches historical and current browser behavior while trying to offer a future behavior that differs. The pragmatic approach has been and will likely continue to be the use of ?method=post at least until we get better browsers adopted across the board...

[friendzis]

The fact that browsers are buggy does not allow to list that as expected behavior. It's like "Some cars are made of paper and everyone dies in any collision >20km/h, but let's make this expected behavior" or "some chefs use cyanide instead of salt, therefore force salt manufacturers to add cyanide to all salt". These days it's not like deploying new version of browser to user requires major update to operating system, which would take 5 years to cover 90% of users.