On 27/10/2012 17:56, Michael-O wrote:
> Am 2012-10-27 18:38, schrieb Mark Thomas:
>> 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.
> OK that's a statement. Tomcat does fully support persistent connections
> but there is no state information maintained, right?

Correct. Tomcat fully supports HTTP/1.1 and that requires keep-alive

> The answer would be: There is clearly no way to store any information
> for a given connection context and retrieve throughout the Tomcat code.

Currently, yes.

> 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.

> Thanks for the quick response,

You are welcome.


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to