Erik Bunn created HTTPCORE-346:
----------------------------------
Summary: 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.3-beta2, 4.2.4
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 with the
contents of the
3) Alternatively, would it be possible to modularize HttpAsyncService.state
creation to allow extending 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 work with paired TLS certs.)
--
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]
