https://issues.apache.org/bugzilla/show_bug.cgi?id=54076
--- Comment #6 from Mark Thomas <ma...@apache.org> --- (In reply to comment #5) > (In reply to comment #4) > > There is one work-around already available. Set alwaysUseSession on the > > Authenticator Valve. > > This isn't even a workaround for me. You cannot guarantee that the client > will respond with the JSESSIONID cookie. You could end up with generating a > huge amount of empty sessions. While it might not be a valid work-around for you it may well work for others. One of the purposes of Bugzilla is to provide useful information to others that stumble across an issue, not just to fix the issue for the original reporter. > > I have added support for a second work-around to trunk and 7.0.x. This > > work-around enables HTTP keep-alive to be disabled for specified user-agents > > if they attempt to use SPNEGO. This will be included in 7.0.33 onwards. > > Well, the server admin needs to know the client's UA preemptively. Is this > really feasable? Yes, in some circumstances. 1. In many environments where SPNEGO is used (I am thinking corporate environments) the user agents are fixed, known and controlled. 2. You can always write the regular expression to not match known 'safe' UAs (an inverse match is harder but not impossible to write). 3. Analysis of your access logs will tell you which user agents you are seeing. > The client cannot know that the server is incapable of performing stateful > auth. > I'd rather always write "Connection: close" for general safety. If you prefer to significantly reduce performance for all UAs that wish to use SPNEGO then you are free to use ".*" as your regular expression and send "Connection: close" to all UAs. > > I'm not a huge fan of adding the ability to cache information per connection > > as that goes against the stateless nature of HTTP. That said, I'd be > > prepared to look at a patch that did this and, depending on how invasive it > > was, would consider such a patch for 8.0.x. > > We have discussed this already on the mailing list. Yes, HTTP is stateless > but some auth mechs are stateful. This means that HTTP has to be stateful > somehow. Since this is done on the connection-level, you already have the > statefulness w/o tampering of the HTTP model. Consider that SSL is stateful > too and simply wraps HTTP messages. SSL is not SPNEGO. That is comparing apples and oranges. The complication factor with SPNEGO is that the handshake occurs at layer 7 but the caching needs to be at layer 6. With SSL/TLS everything happens at layer 6. I'm not saying it is impossible, nor am I saying Tomcat would never implement such a scheme. I am saying I don't particularly like the idea but am prepared to consider any patch proposed. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
