On 27/10/2012 16:28, Michael-O wrote: > Am 2012-10-27 16:57, schrieb Mark Thomas:
>> The only mechanism to maintain state between HTTP requests is the HTTP >> session. You might be able to hack something together (in a non-portable >> way) on a per connection basis but that is likely to require some rather >> major internal surgery for Tomcat (and may be rejected by the >> committers). > > Is there no way to tell that subsequent n requests come from the very > same socket connection? HTTP is just on top of TCP/IP. Something like > this should be transparent to HTTP though? > I am curious, since I know server implementations which indeed DO > maintain state without HTTP sessions but I do not know how they do that. It is easy if the same request object is reused for each request processed for a given connection. Tomcat doesn't do this. When a connection has data to process, first a processor is taken from the processor pool to process the data. The processor has a request object that is re-used. Each time an HTTP request is processed, a different processor and request object may be used. (This does vary slightly between the different connections but lets not complicate things). Undoing this is the major internal surgery I was referring to. You might be able to add an API to store/retrieve data to/from the connection (similar to notes on the session, but at the connection level) and access this from the authenticator (that is a lot further up the stack). That could still end up being pretty invasive. > At least the chromium link says how this can be done. Apache HTTP Cient > does that too. Why not Tomcat? I didn't say it couldn't be done. See above. >> It isn't unreasonable for use of an authentication to require an HTTP >> session. FORM auth does that so I don't immediately see why SPNEGO can't. > > FORM auth works very different compared to header-based auth. Form is > meant for human interaction with a browser which will always pass cookies. > I cannot expect that from a "machine" client nor can the client actively > say destroy that session unless a specific URL is called. "Connection: > close" can do that. Yes there are differences and it places requirements on the client but that doesn't make it a complete non-starter. I agree, if this can be done per connection it would be a lot better. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
