Hacker News Reader

Comment by franze | Hacker News Reader

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.

View on HN

It still seems to be a problem.

I just tested it in Firefox on a Mac. I restarted Firefox. I even rebooted. Developer Tools > Network tab says "cached". I can't confirm that it is cached forever, but it is not only "for the current browser session".

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

Here's the relevant Gecko (Firefox) code which tries to use the max-age and expires headers first and then will set it to forever if the response code was 300, 410, 301, or 308. Note that I'm going by a somewhat shallow code reading after a recent investigation. There's a lot of stuff going on in gecko/necko that could potentially apply some failsafe time limit, maybe in the cache implementation, so I wouldn't take this as 100% for sure. Breaking on this function with gdb and tracing the flow is probably a better idea if you really want to know.

https://dxr.mozilla.org/mozilla-central/source/netwerk/proto...

The 301, 308 stuff comes from IsPermanentRedirect which is here: https://dxr.mozilla.org/mozilla-central/source/netwerk/proto...

Browsers have not changed in this regard.

Are you sure you tested with a 301 redirect (with no caching headers) and not 302 or one of the others? I've been bit by 301s personally.

Reply on news.ycombinator.com