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 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? The connector has to close the connection in my opinion.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
