[Webkit-unassigned] [Bug 71509] WebKit doesn't respect Vary: Cookie header

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Nov 17 13:15:28 PST 2011


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


Robert Brown <rjb at robertjbrown.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rjb at robertjbrown.com




--- Comment #1 from Robert Brown <rjb at robertjbrown.com>  2011-11-17 13:15:28 PST ---
I am having the same issue, specifically with Safari 5.1.1 (7534.51.22) for both MacOS and Windows. Chrome does not exhibit this behavior.

I can reproduce as follows.

1) Visit a webpage, /myurl. Returned headers are as follows:
Cache-Control: public, max-age=3600
Expires: Sun, 11 Mar 1984 12:00:00 GMT
Vary: Cookie,Accept-Encoding

Note that there are no cookies presented to the client at this time.

2) Authenticate to the site. A single session cookie is created for the client browser. During the authentication process, the user is redirected to a different URL. 

IE, during this step a POST is made to the same URL, and it receives a 302 Found to redirect to a different URL. I have verified at this point that the session cookie has been properly created.

3) Navigate back to the original page, /myurl. Even though a cookie is present in the browser and the URL had Vary:Cookie set, the browser serves up a cached webpage. I have run a network sniffer and verified that it does not make a connection back to the server for a new page.

I did verify that if I modified the original Cache-Control header to no-cache, this does not happen. So it definitely has to do with Cache-Control and Vary.

I can reproduce this 100% of the time, and I'd be happy to provide a test login to my site if you have an interest in viewing the details. I also have network sniffer captures and ngrep output.

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



More information about the webkit-unassigned mailing list