[
https://issues.apache.org/jira/browse/HTTPCORE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Bunn closed HTTPCORE-346.
------------------------------
Resolution: Not A Problem
HttpContext provides indirect access to NHttpConnection using key
HttpCoreContext.HTTP_CONNECTION (4.3) or
ExecutionContext.HTTP_CONNECTION (4.2.x)
NHttpConnection instance provides a context that works as expected.
> NIO: HttpAsyncService should couple IOSession and HttpContext
> set/getAttribute()
> --------------------------------------------------------------------------------
>
> Key: HTTPCORE-346
> URL: https://issues.apache.org/jira/browse/HTTPCORE-346
> Project: HttpComponents HttpCore
> Issue Type: Wish
> Components: HttpCore NIO
> Affects Versions: 4.2.4, 4.3-beta2
> Reporter: Erik Bunn
> Priority: Minor
>
> Under httpcore-4.1, I wrote code that attached identifying information
> (unique certificate id) to the IOSession attribute context in SSL
> verification (where we have access to IOSession only, ), and utilized that
> information at the request processing stage (where we have access to
> HttpContext). HttpContext.getAttribute() proxied to its parent context,
> eventually reaching the IOSession attributes.
> The refactoring for 4.2.x async processing has decoupled the HttpContext
> object available in the HttpAsyncRequestHandler implementation methods from
> the IOSession. Looking at HttpAsyncService.processRequest(), you can see that
> it provides HttpAsyncRequestHandler.handle() and .processRequest() with the
> (always empty) BasicHttpContext contained in its state.context.
> At both locations, HttpAsyncService does have access to the
> NHttpServerConnection containing the previously established
> SessionHttpContext seen by IOSession.
> 1) Could this context be sent to the HttpAsyncRequestHandler, instead of
> state.context?
> 2) Alternatively, would it be possible to initialize state.context attributes
> with the contents of the session attributes in HttpAsyncService.connected() ?
> 3) Alternatively, would it be possible to modularize HttpAsyncService.state
> creation to allow extending the class and customizing this behaviour?
> There may be security or nio object reuse implications that I am not
> immediately seeing, and which might invalidate connecting the attribute
> storage in this way. I would appreciate your input if that is the case. If
> not, I would claim this is a bug in the recent nio HttpContext refactoring.
> (Marked as minor under the assumption few people need to carry information
> between such separated stages of iosession and request.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
