Steps to replicate problem: 1) clear firefox cache 2) load url "http://localhost:8080/aaa/index.html" 3) fill in auth form 4) on index.html page click logout link to logout.jsp (invalidate session and redirect to index.html) 5) fill in auth form 6) you will get form page again (!) 7) click "reload" button 8) you will get index.html Conversation with server: firefox: GET /aaa/index.html HTTP/1.1 tomcat: HTTP/1.1 200 OK ETag: W/"478-1193216820000" Last-Modified: Wed, 24 Oct 2007 09:07:00 GMT <page with login form> firefox: POST /aaa/j_security_check HTTP/1.1 tomcat: HTTP/1.1 302 Moved Temporarily Location: http://localhost:8080/aaa/index.html firefox: GET /aaa/index.html HTTP/1.1 If-Modified-Since: Wed, 24 Oct 2007 09:07:00 GMT If-None-Match: W/"478-1193216820000" tomcat: HTTP/1.1 200 OK ETag: W/"316-1193222364000" Last-Modified: Wed, 24 Oct 2007 10:39:24 GMT <page with protected content -- index.html> firefox: GET /aaa/logout.jsp HTTP/1.1 tomcat: HTTP/1.1 302 Moved Temporarily Location: http://localhost:8080/aaa/index.html firefox: GET /aaa/index.html HTTP/1.1 If-Modified-Since: Wed, 24 Oct 2007 10:39:24 GMT If-None-Match: W/"316-1193222364000" tomcat: HTTP/1.1 200 OK ETag: W/"478-1193216820000" Last-Modified: Wed, 24 Oct 2007 09:07:00 GMT <page with login form> firefox: POST /aaa/j_security_check HTTP/1.1 tomcat: HTTP/1.1 302 Moved Temporarily Location: http://localhost:8080/aaa/index.html firefox: GET /aaa/index.html HTTP/1.1 If-Modified-Since: Wed, 24 Oct 2007 09:07:00 GMT If-None-Match: W/"478-1193216820000" tomcat: HTTP/1.1 304 Not Modified ETag: W/"316-1193222364000" firefox: GET /aaa/index.html HTTP/1.1 If-Modified-Since: Wed, 24 Oct 2007 09:07:00 GMT If-None-Match: W/"478-1193216820000" Cache-Control: max-age=0 tomcat: HTTP/1.1 200 OK ETag: W/"316-1193222364000" Last-Modified: Wed, 24 Oct 2007 10:39:24 GMT <page with protected content -- index.html>
Created attachment 21032 [details] web app with form-based authentication war to reproduce described behaviour
Comment on attachment 21032 [details] web app with form-based authentication war to reproduce described behaviour. You need also configured user with role "aaa". It is my $CATALINA_HOME/conf/tomcat-users.xml: <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="aaa"/> <user username="aaa" password="aaa" roles="aaa"/> </tomcat-users>
After looking a bit into source i found (FormAuthenticator.java) save/restore mechanism for requests done before/after authentication. I don't understand needs for it, particularly for save/restore ALL request headers. IMHO restoring headers like "If-None-Match" is incorrect. After commenting out lines (403-412) which serve to restore request headers problem not occurs.
Created attachment 21046 [details] Patch so that complient browsers don't think the login page is the real page Tomcat needs to replay the original request exactly to have any hope of working. This patch, against 6.0 trunk, should prevent any modern browser confusing the login page with the actual resource that it requested.
(In reply to comment #4) > Created an attachment (id=21046) [edit] > Patch so that complient browsers don't think the login page is the real page > Tomcat needs to replay the original request exactly to have any hope of > working. This patch, against 6.0 trunk, should prevent any modern browser > confusing the login page with the actual resource that it requested. Ok, so I'm having a brain-dead moment (seem to be pretty common around here :). This patch should do nothing at all, and it is a FireFox bug that you are looking at (it shouldn't be sending 'if-modified-since' and 'if-none- match' headers, since it was already told that the page is uncachable).
(In reply to comment #5) > Ok, so I'm having a brain-dead moment (seem to be pretty common around > here :). This patch should do nothing at all, and it is a FireFox bug that > you are looking at (it shouldn't be sending 'if-modified-since' and 'if-none- > match' headers, since it was already told that the page is uncachable). IMHO it isn't firefox bug. RFC2616 (14.9.1 What is Cacheable) about "Cache-control: no-cache" says: If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests. So because tomcat sends for static resources "ETag" and "Last-Modified" headers it allow to make REVALIDATION by firefox.
Created attachment 21057 [details] Attempt to get around FireFox's aggressive caching From my reading of RFC 2616, this should work, since FF won't attempt to revalidate a page that it doesn't have in it's cache. If it doesn't work, than I consider it an FF bug (since the login page isn't in it's cache from 2616).
(In reply to comment #7) > From my reading of RFC 2616, this should work, since FF won't attempt to > revalidate a page that it doesn't have in it's cache. If it doesn't work, than > I consider it an FF bug (since the login page isn't in it's cache from 2616). IMHO acording to RFC2616 (14.9.2) "Cache-control: no-store" header not clearly forbids caching response in VOLATILE storage such as memory. My understanding RFC2616 is following: to make response uncachable one should send "Cache-control: no-cache" and NOT send headers used for revalidation such "Etag" and "Last-Modified". But the problem is IMHO in save/restore mechanism.
Created attachment 21063 [details] Patch to disable conditionals headers on a replay for Form Auth Ok, I'm convinced that it needs to be done in the replay. If you are able to actually try out this patch, and post here, it will probably speed up getting it into the 6.0 tree.
(In reply to comment #9) > If you are able to actually try out this patch, and post here, it will probably > speed up getting it into the 6.0 tree. Patch is working for me. Thanks.
The patch has now been committed to SVN, and will appear in the next version of TC 6.x.