Comment #2 on issue 6450 by sant9442: Cookies set during a 401 are not applied to the restarted transaction http://code.google.com/p/chromium/issues/detail?id=6450
Good technical catch! Not sure if this applies, but the original logout response is a 403. So possibly the 403 should be part of the fix as well. -------Request (T1) ----------- GET /logout HTTP/1.1 Authorization: xxxxxxxx Cookie: sessionid=###### -------Response (T2)---------- HTTP/1.0 403 Logging out - Closing Brower Request Set-Cookie: sessionid=signedoff -------Request (T3) ----------- Return to Home Page GET / HTTP/1.1 Authorization: xxxxxxxx Cookie: sessionid=signedoff So the T2 403 response should invalidate the header for any subsequent request. At the web server, the T3 request with the signedoff cookie triggers the server to redirect to the public home page. Without the cookie, it will authorize entry to the private home page. -------Response (T4) ---------- HTTP/1.0 302 found Location: http://beta.winserver.com/public/default.wct I am going to try to clear the cookie here to see if that works around this issue. I want to note that this HTTP AUTH + cookie status technique to invalidate the Authorization header is not exclusive to our server. It was found awhile back in some PHP resource article as a method to authorize different web pages, so probably it is more common than just with us. Thanks -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs -~----------~----~----~----~------~----~------~--~---
