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