Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Thu, 25 Jul 2013 08:55:49 +0000 (UTC)
From: "Erik Bunn (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12659622.1374685856120.110304.1374742549128@arcas>
In-Reply-To: <JIRA.12659622.1374685856120@arcas>
References: <JIRA.12659622.1374685856120@arcas>
Subject: [jira] [Commented] (HTTPCORE-346) NIO: HttpAsyncService should
 couple IOSession and HttpContext set/getAttribute()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCORE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719400#comment-13719400 ] 

Erik Bunn commented on HTTPCORE-346:
------------------------------------

Oleg;
I'm working in an SSLSetupHandler on one end, and an HttpAsyncRequestHandler on the other; the execution context is not available through these interfaces. 

I'm looking into other ways to approach this. The original came about precisely because I noticed that the 4.1 code does connect the session and httpcontext attributes. (I can emulate the 4.1 behaviour by creating my own HttpAsyncService and overriding its State setup, but package visibility in those classes forces me to use package org.apache.http.nio.protocol and is very kludgy.)

As I said, it's probably rare that someone needs to communicate from SSL setup to request context - I'm using this for an additional client spoofing check, and have to re-evaluate whether it's sensible here. Just wanted to point out that there's a change in attribute code.

Thanks,
//erik


> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org