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: [email protected] For additional commands, e-mail: [email protected]
