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]
