hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Three different HttpContext in HttpAsyncService
Date Mon, 06 Oct 2014 09:19:12 GMT
On Mon, 2014-10-06 at 11:35 +0400, Dmitry Potapov wrote:
> Hello everyone,
> 
> Until today I was under a misapprehension that there is single HttpContext
> travels across handlers and callbacks during request processing. Today I've
> discovered that during single request processing HttpAsyncService can operate
> with three different HttpContext:
>  1. BasicHttpContext created in .requestReceived(). This context will have
>     HTTP_RESPONSE and HTTP_CONNECTION attributes.
>  2. BasicHttpContext created in .exception(). In case of HttpException thrown
>     from HttpAsyncRequestHandler.handle() function, this context will be empty.
>  3. SessionHttpContext created by NHttpConnectionBase.setSession(). This
>     context will be passed to ConnectionReuseStrategy.keepAlive() and will have
>     HTTP_CONNECTION set, but no HTTP_RESPONSE.
> 
> Is this contexts separation is intentional and there are some reasons to have
> them separated and containing different set off attributes?
> As for me, it seems reasonable to use NHttpConnection.getContext() in all three
> cases listed above. Which pitfalls I'm missing here?
> 

Dmitry

HTTP sessions can span across multiple connections (this is especially
applicable to the client side where it is pretty common) and the same
persistent connection can be used by multiple logical sessions. So,
HttpCore attempts to maintain a clear distinction between connection
contexts and execution contexts, which are often not the same. 

Point (2) is really a fringe case intended to ensure there is a context
of _some_ sort even in case an exception is caught before the session is
fully set up.

Point (3) sounds like a bug to me. However, it does not seem to be the
case in the latest revisions of trunk and 4.3.x. If I missed something
please do let me know or, better yet, submit a pull request ;-)

Oleg 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message