http://mark.koli.ch/2010/12/set-cache-control-and-expires-headers-on-a-redirect-with-mod-rewrite.html

Yeah! Of course this doesn't fix existing problems, but at least moving forward I've found a new best practice that I'll be following.

And given that the mnemonic in the spec is "Moved Permanently", I don't think URL shortening was "the reason that 301 was created".

I believe some URL shorteners also allow editing of the redirect, so would need to be careful of cache control!

Why is there no override? What sense can it possibly make to provide no override whatsoever?

Amazing... and disappointing...

Perhaps I worded that rather more confrontationally than was necessary. What I was trying to say was that the points I've raised don't just apply to 301 redirects under a particular scenario that I have encountered, they apply to *any* use of HTTP status 301. It is not the case that developers only use status 301 because they are not aware of status 302, so clearly they are choosing it for some reason, based on their understanding of the differences between the two.

I considered the advantages of status 301 to be somewhat beside the point - either it has a use, and the issues need exploring, or it has none, can safely be removed from the HTTP spec, and the whole issue is moot.

> "Maybe they should've thought about the implications beforehand"

Again, this assumes that web developers have had it "wrong" for years, and Firefox is now "right".

The HTTP standard has included status code 301 since at least 1996 (http://www.w3.org/Protocols/HTTP/1.0/spec.html#Code301). [Interestingly, the statement that "this response is cacheable unless indicated otherwise" is not in that spec, so was presumably added when drafting HTTP/1.1.] As far as I know, until 2010, no major browser cached 301 redirect information in the way we're discussing.

During that 14 year period, developers therefore didn't think about caching implications because there were none. Even if the spec had unambiguously stated that an unqualified 301 response was liable to eternal caching (which it does not), common practice does not include sending cache-control headers with every redirect, because doing so would have made no difference in practice.

> "Trying to fix ignorance is not a technical issue."

No, but compatibility with existing implementations is. If a browser came out that refused to render any web page that did not strictly adhere to its declared doctype, it would be considered broken, even though it was adhering to well-established specifications. Fixing every 301 redirect in the world is not a trivial task, however desirable, so dealing with the ones that are there is unavoidable.

[Sorry if this is a bit long and rambling, I'm not very good at being concise!]

"There are plenty of valid reasons to use 301 redirects, including the fact that indexers such as Google will handle them differently." - This is not something you pointed out in the article. Your article merely looked at the problems it caused you and the suggestions you have for it. If there are good reasons for a 301 you should state them and provide a balanced view.

"Any solution that says that web admins need to change their code" - Maybe they should've thought about the implications beforehand, as you have clearly and correctly done and made the better choice for them. Trying to fix ignorance is not a technical issue.

Suggestion 1:

Even if we accept that the standard says that a 301 response without caching headers can be considered eternal (and there is plenty of room for debate on that point); and even if changing code to produce redirects with cache control was trivial (which it is not, for instance, with mod_rewrite); even then, the fact is that this is not the current behaviour of websites in the Real World.

Changing the behaviour of code which previously wasn't cached at all to being cached for the lifetime of a user's browser profile is a pretty major change. Again, I can't actually think of a scenario where an eternal redirect would even be desirable, but it should definitely be something that a developer opts into, not out of. I can't think of any other example of a cache that's quite so immortal.

My suggestion is just to pick a lifetime somewhere below infinity for these "legacy" redirects which don't specify an expiry. Even expiring after a year would give developers a cut-off date after which they could rely on "bad" redirects having expired.

Suggestion 2:

Interesting point, but whatever side effects this would have would also happen in browsers which don't cache redirects. Any site specifically relying on redirect caching behaviour would break for IE<9, Firefox<5, etc. I'm therefore confident no such site exists (or is worth worrying about).

Suggestion 3:

Yes, it's definitely a change in behaviour. Personally, I think that if you're specifically opting for a hard refresh, going back and requesting the URI you originally navigated to is probably a good thing. It would certainly need careful implementation, though, in case it created any new side effects. Of all of my suggestions, I consider this the least likely to be implemented, which is a shame, because it would make testing Apache configurations a lot less painful!