At least on three counts - in user agents, in crawlers and in RFC: - 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 foreve…
Permanent meaning anything other than permanent violates the Principle of least astonishment.
In their defense that is probably the case of their MVC framework or CMS returning a 200 after not being able to match the route and not really them doing it on purpose. 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…
I would say this falls under web professionals not understanding their framework, which is at least as common a problem as not understanding HTTP.
Heck, it might even be more common. Especially when you talk about huge frameworks like Spring for Java. Also, with CMSes like Wordpress I imagine you can't really change the status that easily if it's not returning what you'd expect. I'm not saying a WP 404 page DOESN'T return 404, but if it returned 200, how far would you have to dig to change that? If my CMS wasn't doing it exactly right, I would probably just shrug and move on unless it was critically important to something I was writing against it.
This is a browser design issue not a protocol/server issue. At the time HTTP 1.1 was written browser caches would hold at most a few weeks of browsing history before things started falling out so 'permanent' functioned like our intuition
Whats more surprising is "13.2.2 Heuristic Expiration"[1]
If you specify (or your framework does) a Last-Modified time WITHOUT Cache-Control the browser is free to make up its OWN cache expiration rules (the item is implicitly cacheable)
At least on three counts - in user agents, in crawlers and in RFC: - 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 foreve…
Permanent meaning anything other than permanent violates the Principle of least astonishment.
See my original post - permanent Permanent Redirect works as designed ;) I was later trying to point out possible ambiguities in how the spec is interpreted vs. how it's written.
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.
In their defense that is probably the case of their MVC framework or CMS returning a 200 after not being able to match the route and not really them doing it on purpose. 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…
That just pushes "web professionals not understanding HTTP" one level down the stack, except this "web professional" is not the user doing the clicky, but whoever made the framework; the problem remains unchanged.
Sometimes it's a disagreement over what it's reasonable to expect from a framework user. Framework developers expect the users to read their docs and use their API only the way that's documented. Users expect any given API method to do what it says.
2012 - somebody should write 2012 into the title of this post (that by the way hasn't any concrete data) I did some testing in 2009, think around 2012 and 2014. Additional to loffilegrepping after some big site URL rewrites. It's a non issue. No caching headers, the redirect gets cached only for the current browser session. Close it, reopen it, gone, done. Lets discuss this one based on data. (Which I cant provide ri…
The problem with 301 without cache headers is that some browsers cache this forever due to some interpretation what 'permanent' means. You often can't use 302 because all your external links no longer work SEO magic for you with a 302. Google only transfers link juice with 301 [1]. If you make a mistake and misconfigure your server, you're toast. If a disgruntled employee 301 redirects your domain, you're toast. If a…
> If a hacker (from a competitor) 301 redirects your domain, you're toast. Reminds me of the guy that "got hold" of Google's domain for a few minutes. What if something similar happened and someone were able to make this redirect? Millions would be affected.
Nope, IIRC he didn't technically own the domain, it just showed up in his account as owning it (therefore he could have viewed analytics and other information) - but he didn't actually have permission to change the domain.
The problem with 301 without cache headers is that some browsers cache this forever due to some interpretation what 'permanent' means. You often can't use 302 because all your external links no longer work SEO magic for you with a 302. Google only transfers link juice with 301 [1]. If you make a mistake and misconfigure your server, you're toast. If a disgruntled employee 301 redirects your domain, you're toast. If a…
I think that when you clear the cache on recent versions of Chrome it also removes 301 redirects. I'm not sure though.