[Webkit-unassigned] [Bug 84478] New: Chrome Canary ignores Cache-Control header

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=84478

           Summary: Chrome Canary ignores Cache-Control header
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Windows 7
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: eddie at page.ca


Created an attachment (id=138143)
 --> (https://bugs.webkit.org/attachment.cgi?id=138143&action=review)
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.