Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

301 redirects: a dangerous one way street (2012)

jacquesmattheij.com

Post reply on HN
Print view View original

11–20 of 92 posts

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

#11

Post by mnw21cam »

pluma wrote: post #5

"There are only two hard things in Computer Science..." I guess some people think the purpose of 301 is more like that of 410: update references so you don't try to go there again. The difference is that with 301 you additionally instruct the client to not even attempt to go there again in the future. But the article does raise an interesting point: if I own somedomain.example and set it up with a 301 redirect to myo…

For an important busy web site, even serving up a redirect for a short amount of time could be enough to cause some serious problems. It's a way of turning "I hacked and defaced this website but they fixed it 24 hours later" into "I hacked and defaced this website and they fixed it 24 hours later, but loads of people still see the defaced version".

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

#12

Post by sparewalking »

zephod wrote: post #7

I took over a domain which had previously 301-redirected HTTP:// to HTTPS://. It caused us no end of trouble getting the alpha site online -- obviously we set up SSL but we didn't realise it was the _first thing we'd have to do_. It also caused half a day of confusion to understand why some of our web browsers were still failing to connect and others could see the alpha site (because they'd never visited the previous…

In such cases I always compare 'curl -I site' with the affected browser console.

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

#14

Post by Typhon »

Piskvorrr wrote: post #2

That's what permanent means. "Adjective permanent Without end, eternal. Lasting for an indefinitely long time. " 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.

This seems yet another example of web professionals not understanding HTTP.

Much like webpages that say "404 not found" with a "200 OK" header.

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

#15

Post by _yy »

Piskvorrr wrote: post #2

That's what permanent means. "Adjective permanent Without end, eternal. Lasting for an indefinitely long time. " 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.

Maybe it's bad design, then?

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

#16

Post by TazeTSchnitzel »

pluma wrote: post #6
TazeTSchnitzel wrote: post #4

HSTS is similarly one-way, but it's not indefinite, I think.

It's not indefinite because you need to specify a duration. However nothing stops you from setting an extremely long duration and in fact most tutorials seem to advise doing so for safety reasons.

Yeah, a short duration is practically useless. I've seen one site that sets the duration to a mere 24 hours.

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

#17

Post by kijin »

I was recently burned by this. The client had left his server misconfigured for a few hours, and a lot of his static content ended up in a redirect loop. I was called in to fix the mess.

Although modern browsers are clever enough to detect a redirect loop and throw an error, they're not clever enough to detect when the redirect loop is caused by a cached 301 response. So they cache the redirect loop as well. Throw in another layer of caching (CloudFlare), and now you've got a bunch of URLs that will be stuck in a redirect loop for a very long time.

The only solution was to append some garbage to every URL, like "?cache=no". Fortunately, the problem only occurred with static content, so nginx happily discarded the querystring and returned fresh content.

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

#18

Post by Piskvorrr »

_yy wrote: post #15
Piskvorrr wrote: post #2

That's what permanent means. "Adjective permanent Without end, eternal. Lasting for an indefinitely long time. " 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.

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.

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

#19

Post by franze »

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 right now as Im on a beach on Sri Lanka right now with a FirefoxOS device amd I dont know how to see Http requests on this one, but) Please prove me wrong! based on test, data, not blogposts.

Post reply on HN