UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce the problem:

1. Incognito or normal mode is affected.
2. visit an http website url [a] that contains a 302 redirect to an https url [b] returning status 200 OK. this loads the cache. the page was encrypted during transport. 
3. alter the server redirect from [a] to [b] such as to remove the redirect completely, ie url [a] should display always serving code 200 OK and the unencrypted content.
4. visit url [a] again.
5. press reload
6. insert query strings like ?suxbugugot eg http://localhost:8888/?suxbugugot
7. visit url [a] again in a freshly opened Incognito window. 
8. delete all cached images and visit url [a] again.

also seems to affect:
Chrome Version       : 12.0.742.122 (Official Build 91910) see url [c] 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 see url [d] 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 

What is the expected behavior?
Chrome should expire cached redirects to error pages (type 400 500 etc).
Chrome Incognito leaks personal data about browsing habits of main profile by way of this bug. 

Initially,  at step 2 chrome will mostly* correctly follow and then store the content, but at step 4 when the reload button is clicked (either in toolbar or in the page content), chrome should delete the cached entry and retry url A. 

For the incognito mode, for step 5 chrome show behave like it's never seen the page before. the cached redirect still applies showing Incognito mode can leak information about a users browsing history from the main profile.

I think I have even tested this purely in Incognito and it still works but for this bug report I did not test that. 

[a] http://localhost:8888/ (wordpress site: may have canonical + js redirect? then how come safari and firefox work fine?!!) live site is at https://www.solarnetwork.nz/
[b] https://solarnetwork.nz.dev:8888/

OTHER BROWSERS do the right thing: url [a] is shown 

steps 5, 6, 7, 8 reinforce the depth and annoyance of this issue. 

What went wrong?
url b was dispayed. 

I say mostly because it's therefore possible to defeat the Incognito claim "it doesn't store browsing history". Firing up a fresh incognito session incorrectly follows the cached 302 but then tries to load url [b] which is a huge 400 or 500 error. This should never have been possible and maybe I can claim a bounty if Google have one for that browser. 

Did this work before? N/A 

Chrome version: 64.0.3282.140  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

some bugs are features. i fail to see how this is a feature, especially considering the INFORMATION LEAKAGE ISSUE in incogito!

ALSO consider our community has been keen to hear about a fix since at 2011 see:
[c] 2011 https://bugs.chromium.org/p/chromium/issues/detail?id=91740
[d] 2017 https://bugs.chromium.org/p/chromium/issues/detail?id=775435 
[e] 2017 https://bugs.chromium.org/p/chromium/issues/detail?id=677755 
[d] 2011 https://superuser.com/questions/304589/how-can-i-make-chrome-stop-caching-redirects
 

Deleted: chrome redirect cache bug.png 101 KB

	chrome redirect cache bug.png 101 KB View Download