Live data from Hacker News

301 redirects: a dangerous one way street (2012)

jacquesmattheij.com

61–70 of 92 posts

Re: 301 redirects: a dangerous one way street (2012)

#61
post #53

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 ca…

Heuristic Expiration is a case of documenting existing weirdness. Older browsers would have cache expiration policy be a setting the user could control, so you can't really leave off explicit headers with any expectation a default will be respected.

Re: 301 redirects: a dangerous one way street (2012)

#63
post #36

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…

Thanks for this. Can you please share an example of the cache headers you add to 301 redirects?

Something along these lines:

http://mark.koli.ch/set-cache-control-and-expires-headers-on...

Re: 301 redirects: a dangerous one way street (2012)

#64
post #19

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…

What data do you need? This is empirically observable. Half the people in this thread are giving you examples.

Re: 301 redirects: a dangerous one way street (2012)

#65

Earlier quoted context omitted.

It's certainly doable, but, what are you seeing as a benefit?

Possibility to check a domain before you buy it.

moron... it's not what it's doing NOW... it's what it ever HAD done, as anyone who visited it THEN is now locked out.

how any of you hold jobs is beyond me. i'll keep coming in and cleaning up your messes.

Re: 301 redirects: a dangerous one way street (2012)

#66
I saw this article at approximately the same time as I saw this tweet: https://twitter.com/P0TUSTrump/status/684891719985410048 .

--- begin factually incorrect statement ---

  To save you a click: Jeb Bush forgot to renew his domain, 
  and Trump bought it and redirected to 
  www.donaldjtrump.com

  Thankfully, Trump is using a 302, not a 301.
--- end factually incorrect statement ---

EDIT: ah I see -- jebbush.com has only ever had that redirect throughout its entire (short) existence. Leaving my comment up though, since it's more about what one could do in that scenario than any particular current event.

Re: 301 redirects: a dangerous one way street (2012)

#67
I thought best practice these days, at least for REST, was a 308 (https://tools.ietf.org/html/rfc7238), since 301 has the bizarre behavior of being converted to a GET by some UAs (which conflate it with 303), enshrined for hysterical raisins. Is this not the case?

Re: 301 redirects: a dangerous one way street (2012)

#68
post #51

Earlier quoted context omitted.

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.

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.

Re: 301 redirects: a dangerous one way street (2012)

#69

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.

Same with Firefox

Re: 301 redirects: a dangerous one way street (2012)

#70
post #66

I saw this article at approximately the same time as I saw this tweet: https://twitter.com/P0TUSTrump/status/684891719985410048 . --- begin factually incorrect statement --- To save you a click: Jeb Bush forgot to renew his domain, and Trump bought it and redirected to www.donaldjtrump.com Thankfully, Trump is using a 302, not a 301. --- end factually incorrect statement --- EDIT: ah I see -- jebbush.com has only eve…

That's not Trump, it's a fan account
Post reply on HN