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. > 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
