[aprescott]

While browsers can probably "do anything" with a 301 or 302, I think in practice it's simpler.

I think the issue here is that 301 and 302 were originally intended to preserve the HTTP method but they became permanent and temporary versions of "issue a new request with a GET". So to try and fix that they provided 307 (and now 308) as temporary and permanent versions of "this resource changed location, so reissue this request at the new URL".

I actually wrote a post about this a couple of days before RFC 2616 got marked for official deprecation: https://aprescott.com/posts/http-redirects

I plan on updating that with more information once a proper RFC deprecates 2616 and 308 makes its way into something other than a referenced alternative, as it is in the current draft last time I checked.

Also, for fun, try pointing curl at a server returning various response codes and see what it does with `-X [method]` and compare it with the latest Chrome and Firefox.

[6cxs2hd6]

I thought OP said the situation with 301, while not perfect, is much much better than 302. Even if clean-slate 307 and 308 codes is a great idea, I think OP is concerned that redefining 301 to be excessively permissive will make things worse not better -- in that 301 will go from fairly reliable to being as bad as 302.

[aprescott]

302 is already bad, and 301 is already wrongly implement as RFC 2616 itself notes. Ultimately I doubt either is going to see a "fixed" implementation from a buggy one that's lasted as long as it has.

[andrewflnr]

That doesn't answer the question, namely, "will loosening the definition for 301 make things worse than not changing it?". In this thread I've not seen a solid argument that it won't make things worse, only long redirections (ha!) from the point. Are you saying that 301 is so widely, badly implemented as to be a lost cause, as the author concedes 302 is?

[aprescott]

I don't know enough about client implementations to say whether it is unsaveable, but let's say it is: why would 308 exist? That suggests the HTTP spec folks believe it's fundamentally changed meaning. With new-301, new-302/303, 307 and 308, we'd cover each of the 4 cases. Seems to strongly suggested that's necessary.

[andrewflnr]

You can't just "let's say" 301 is unsaveable, because that's the only outside fact that determines whether TFA's argument is correct. You seem to be assuming that the committee's decision is evidence that it's a good idea, which is exactly what TFA is trying to determine.

Meanwhile, hobohacker got around to answering the real question.