Hacker News Reader

Comment by _yy | Hacker News Reader

Maybe it's bad design, then?

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 forever', that is a long time"; it does not try too much to prevent implementors from shooting themselves (and users) in the feet.

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.

I would argue that your statement is only true as long as the URL in question is owned by the application that sent the 301 in the first place. If a different application now owns the URL, then it violates least astonishment for the URL to be redirect when, from it's perspective, the redirect was never sent.

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.

Reply on news.ycombinator.com