Also, "This response is cacheable unless indicated otherwise," says RFC 2616.
Working as designed, IMNSHO. Perhaps not working as intended, but alas, that's a case of ¬RTFM.
Much like webpages that say "404 not found" with a "200 OK" header.
But yeah, I agree- (though I've missed them I'm sure) I pretty voraciously make sure my HTTP status matches my intended response- and sometimes that means you've got to write the code in the controller that tells the request to specifically return a certain status.
/quote RFC2616 (So, the status line is an entity of its own, which is followed by headers.)
- I definitely see bad design in interpreting the RFC as "if no caching metadata, then cache forever;" this violates Principle of Least Astonishment.
- Also, "301 and 302 has completely different meaning to a crawler" seems illogical.
- Perhaps the RFC should have also specified something like "in absence of caching headers, don't assume 'cache forever', that is a long time"; it does not try too much to prevent implementors from shooting themselves (and users) in the feet.
At the least, a redirect should not be permanent across name server changes (when the domain changes hands). Unfortunately, this would effectively be adding state to HTTP.
In defense of the browsers - the RFC does say, in essence, "rewrite the 301'd URL and be done with it," so the browser does not even need to deal with the redirect any more.