hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: NIO HttpCore - Can requestInput result in two new requests
Date Mon, 18 Aug 2008 16:13:12 GMT
On Mon, 2008-08-18 at 08:46 -0700, Rae Egli wrote:
> Oleg,
> 
> 
> 
> > I chose a reverse proxy as an example primarily due to the fact that a
> > reverse proxy can get away with a much simpler connection management
> > logic than a normal caching proxy. 
> 
> > One needs a significantly more complex logic for managing connections to
> > origin servers when implementing a production level caching proxy. It is
> > simply out of scope for HttpCore.
> 
> I understand.  I just wanted to point out the flaw.  Note that the reverse proxy, in
particular, is vulnerable to this bug as it ALWAYS has the same Origin/destination connection

I am still not sure this is the case. Please take a closer look the
#connected methods of ListeningHandler and ConnectingHandler. Listening
protocol handler always creates a new ProxyTask instance on each
incoming client connection, requests a completely _new_ connection to
the origin server and passes that ProxyTask instance to the connecting
protocol handler as an attachment. As a result there is always a
dedicated connection to the origin server for each and every connection
to the proxy and the ProxyTask instance is shared by two connections,
one client (incoming), one origin (outgoing). This is over-simplistic
but not necessarily flawed.

So, I fail to see the fundamental flaw here. Am I still missing
something?


>  and therefore always has the same Origin context/ProxyTask.  Therefore, anytime a new
connection arrives before the old one completes, the problem occurs.  I encountered it first
on the original example but at that point didn't understand enough of the issue. 
> 
> > There are plans to start development of connection management components
> > based on HttpCore NIO similar to those that exist for blocking HttpCore
> > either as a separate project within HC or as an extension to HttpClient
> > 4.0. Ideally those efforts should be driven by another contributor /
> > committer. 
> 
> > Hope that clarifies things a little.
> 
> I am looking forward to it. 

Also consider contributing ;-)

Cheers

Oleg


>  Thanks a lot for all your efforts on this project.  I like it a lot!
> 
> Raetus
> 
> 
> 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 


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


Mime
View raw message