Re: unauthenticated 304s - final try
Mark Leone sez: 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. that's pretty much what *i* thought, anyway... 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? from the 2.4 Servlet spec: If the user is authenticated using form login and has created an HTTP session, the timeout or invalidation of that session leads to the user being logged out in the sense that subsequent requests must cause the user to be re-authenticated. seems fairly straightforward to me. i agree that the HTTP spec is less than optimally clear, and that this isn't a huge issue - it's just that it excercises a MSIE6 misfeature that html pages are cached, but included .js .css files are not, resulting in the display of ugly broken pages when this happens. --alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: unauthenticated 304s - final try
I see. You're relying on the server's proper implementation of session timeout behavior to force IE to reload a page that hasn't changed, since IE doesn't save all the components of the page. when it caches it. I think your excerpt from the servlet spec is pretty clear, and probably the best recourse for requesting a fix to Tomcat. I think that it's not really a matter of clarity wrt the http spec. It just specifies how a server requests authorization credentials when it wants them, but it's up to the server to decide under what circumstances it wants them. In other words, if 304 is the wrong status in the circumstance you describe, then the only other possible right answer is 401. But the semantics for status 401 just say, in effect, the server sends 401 when it decides it wants authorization credentials. So it's really the server (i.e. servlet) spec that's being violated here, IMO, not HTTP. -Mark From: alexander dosher [EMAIL PROTECTED] Date: 2005/03/28 Mon PM 01:47:34 EST To: Tomcat Users List tomcat-user@jakarta.apache.org Subject: Re: unauthenticated 304s - final try Mark Leone sez: 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. that's pretty much what *i* thought, anyway... 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? from the 2.4 Servlet spec: If the user is authenticated using form login and has created an HTTP session, the timeout or invalidation of that session leads to the user being logged out in the sense that subsequent requests must cause the user to be re-authenticated. seems fairly straightforward to me. i agree that the HTTP spec is less than optimally clear, and that this isn't a huge issue - it's just that it excercises a MSIE6 misfeature that html pages are cached, but included .js .css files are not, resulting in the display of ugly broken pages when this happens. --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]
Re: unauthenticated 304s - final try
It seems to me that the HTTP spec is under-specified on this. I agree that it's reasonable to assume that if access is NOT allowed, and the document has not been modified, the server MUST NOT respond with this status code. However, what I just typed in quotes does not appear in the spec. It says what SHOULD happen when a conditional GET is sent when access is allowed, but doesn't say what may or may not happen when access is not allowed. 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]
unauthenticated 304s - final try
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]
