It's still worth investigating IMO. One could argue that returning to an unauthorized client even the info that a resource has not changed since an authenticated request was returned successfully violates the authentication protection. I guess. But the section on 401-Unauthorized response doesn't indicate under what conditions that response MUST or SHOULD be returned- it just leaves it up to the server to send this response status when "the request requires user authentication." Response status 304 has no meaning except in relation to a successful request, so I'm not sure what the expected behavior is if the client subsequently loses authentication and therefore authorization. Again, the section on 401 response doesn't address this situation.
This may have more to do with the server's authentication requirements than the HTTP spec. Does anyone know if the Servlet spec addresses this?
-Mark
alexander dosher wrote:
before i post this as a bug & possibly make a complete idiot of myself, please have a look...
Tomcat 5.5.7 on Win2k, MSIE6
1. load an authenticated page (JDBCRealm or DataSourceRealm w/SHA, FORM login-config, SingleSignOn valve)
2. wait until authentication timeout OR close browser window & reopen
3. perform a conditional GET (i.e. reload WITHOUT ctl-shift)
Result: Tomcat returns 304 Not Modified. relevant bit of access_log: #.#.#.# - - [datetime] "GET /home HTTP/1.0" 304 - ^ no user!
which is IMHO in violation of the HTTP spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) relevant bit:
If the client has performed a conditional GET request and *access is allowed*, but the document has not been modified,
the server SHOULD respond with this status code.
comments?
--alex.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
