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