On 27/10/2012 19:32, Michael-O wrote: > Am 2012-10-27 20:22, schrieb Mark Thomas: >> On 27/10/2012 18:57, Michael-O wrote: >>> Am 2012-10-27 19:25, schrieb Mark Thomas: >>>>> Is this something worth being filed in Bugzilla as a longterm goal for >>>>> Tomcat 8? >>>> >>>> Sure, but without a proposed patch I suspect it will sit there for a >>>> few >>>> years and then closed as WONTFIX. With a patch, it still might not get >>>> fixed but at least you'll know for sure and if the patch isn't too >>>> invasive (for the benefit it provides) it is likely to be applied. >>> >>> That seems to be very tough. I hacked Tomcat code several times but >>> wouldn't claim that I am firm enough to implement such a tremendous >>> improvement. Interesting though that no one else yet requested such an >>> improvement. >> >> Yes, we are fairly tough on adding new features. We really don't want to >> add what, for most users, is bloat. We are usually happy to add hooks if >> folks need them to implement their particular itch. >> >> I wouldn't worry about the quality of the patch. The first one I wrote >> for Tomcat was (rightly) ripped to pieces by the committers at the time >> but the feature was implemented and is still there today. If a committer >> can see a cleaner way of doing the same thing then they'll either give >> you some pointers or just fix it and apply it. The main point is that if >> there is a change you want to see, then you need do be the driving force. >> >> Adding connection level notes shouldn't be too hard. The trickier part >> is exposing them to the high-level components that need them. Passing >> through the request is probably the way to go. > > As long as there is general interest in such a feature I will keep that > in mind and might take a look at it over Christmas.
I'd certainly be prepared to look at it, both for SPNEGO and SPDY. >>> I have no usecase for this at the moment :-(, I only provide patches for >>> stuff I suffer from at work. >> >> The below looks like a use case to me. >> >>> As this [1] draft lays out Negotiate and Kerberos may apply to >>> connection or request level auth. We are just lucky that the first >>> gss_accept_sec_context makes the context complete in the SPNEGO >>> authenticator. >>> >>> Some clients maintain the state and rely on the server to maintain the >>> connection state too. Tomcat does not do that which means that the >>> current SPNEGO authenticator has to issue a "Connection: close" after >>> successful auth. Otherwise the client will reuse the connection and keep >>> sending requests w/o reauthenticating eventhough Tomcat requires to do >>> so. In this case I have a Wireshark capture where this exactly happens >>> and the clients traps in an endless loop and issues thousands of >>> requests performs a DoS. > > Well, as long as there is support for connection storage should I file a > bug about that? Go for it. > The connector has to close the connection in my opinion. Not sure what you mean by that. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
