RESOLVED INVALID 84478
Chrome Canary ignores Cache-Control header
https://bugs.webkit.org/show_bug.cgi?id=84478
Summary Chrome Canary ignores Cache-Control header
Eddie Roosenmaallen
Reported 2012-04-20 12:22:37 PDT
Created attachment 138143 [details] Screenshot from the web inspector Chrome Version : 20.0.1111.0 (Official Build 133177) canary URLs (if applicable) : Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5:OK What steps will reproduce the problem? 1. Access an HTML page which includes a JS file served with "Cache-control: no-cache" header 2. Leave the page 3. Return to the page via a 302 redirect What is the expected result? The JS file will be requested from the server again What happens instead? The JS file is drawn from the browser cache Please provide any additional information below. Attach a screenshot if possible. We have a web application which uses a session cookie to maintain state, and a JS file (verifySession.js) to verify the session. If the user has a valid session, then verifySession.js sets a sessionUser property on the window, but if not then verifySession.js sets a sessionError property on the window. The correct behaviour is that the user browses to app.html, which includes verifySession.js. Once the page is loaded, embedded JS will check for window.sessionUser, and redirect to the login page if it is absent. The problem we're running into is that Chrome Canary is caching verifySession.js, so after the user is logged in, the JS is not retrieved from the server again. We've verified that the js file is sent with the Cache-Control: no-cache header, and the behaviour is correct in Safari. In testing with Chrome 18.0.1025.162, the problem is present but less persistent - after a small number (2-3) attempts, the browser will fetch the script form the server.
Attachments
Screenshot from the web inspector (137.81 KB, image/png)
2012-04-20 12:22 PDT, Eddie Roosenmaallen
no flags
Alexey Proskuryakov
Comment 1 2022-07-29 09:16:55 PDT
Marking as RESOLVED/INVALID, because Chrome no longer uses upstream WebKit, having forked it.
Note You need to log in before you can comment on or make changes to this bug.