[hobohacker]

I think the author of this blogpost has a few things off:

- HTTP2 != httpbis. Both work is being done by the same working group "httpbis". http://datatracker.ietf.org/wg/httpbis/charter/ covers this. httpbis (http://stackoverflow.com/questions/9105639/httpbis-what-does...) was originally chartered to revise HTTP/1.1 (RFC2616) The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications

As for the HTTP/2 work, here's a snippet from the charter on that: The Working Group will produce a specification of a new expression of HTTP's current semantics in ordered, bi-directional streams. As with HTTP/1.x, the primary target transport is TCP, but it should be possible to use other transports.

- He seems to think the httpbis folks gratuitously redefined 301. It should be noted that RFC2616 (which, by definition, predates the httpbis work since httpbis is defined to revise RFC2616) had already noted the issue with 301 (http://tools.ietf.org/html/rfc2616#section-10.3.2): Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.

- It's unclear to me whether or not the author acknowledges the existence of buggy implementations as noted in section 10.3.2. It's an open question as to what to do in the presence of buggy implementations. From a server standpoint, if the client is buggy, and you don't want to break the client (willingness to break clients probably depends on how many of the server's users use that client), then you will attempt to work around it, irrespective of what the standard says. Therefore, it's simply pragmatic to ignore the spec if it doesn't mirror reality, and pragmatic spec editors may update the spec to acknowledge this difference.

- As far as current status of the various 308 usages, Julian (author of the 308 draft) is lobbying major user agents to adopt this, and has written up a status update on the Chromium bug tracker: https://code.google.com/p/chromium/issues/detail?id=109012#c....

[6cxs2hd6]

It sounds like you're well-marinated in standards bodies, and that's a good thing -- it's tough, often thankless work that someone needs to do.

For the rest of us, the language from OP sure sounds like it's saying, "yeah do whatevs with 301, we give up".

People often read RFCs in a hurry. Wouldn't this be a great place to use the a "SHOULD NOT" (change the request method)?

If you're saying "MUST NOT" would be bad because the horse is out of the barn, I understand. But the draft language now sure sounds like "MAY", and the OP has a good point that it's likely to encourage more wrong behavior, not less.

At least IMHO. Again, I am not a standards lawyer, so please take this feedback accordingly.

[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.