4 ms·

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

by franze 11y ago

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.

rebelde 11y ago
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".
_Codemonkeyism 11y ago
Browsers have not changed in this regard.
zephod 11y ago
What data do you need? This is empirically observable. Half the people in this thread are giving you examples.
AgentME 11y ago
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.
asutherland 11y ago
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/protocol/http/nsHttpResponseHead.cpp#411 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/protocol/http/nsHttpResponseHead.cpp#411 https://dxr.mozilla.org/mozilla-central/source/netwerk/proto...

by franze 11y ago

rebelde 11y ago

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".

_Codemonkeyism 11y ago

Browsers have not changed in this regard.

zephod 11y ago

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

AgentME 11y ago

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.

asutherland 11y ago

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/protocol/http/nsHttpResponseHead.cpp#411 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/protocol/http/nsHttpResponseHead.cpp#411 https://dxr.mozilla.org/mozilla-central/source/netwerk/proto...