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 22:03:58 GMT
Rae Egli wrote:
> Oleg,
> 
> 
> 
>> 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.
> 
> If you look at the log that I initially submitted, you'll see that this instance would
have immediately caused trouble with the reverse proxy.  You are right that every new connect
causes a new ProxyTask to be established.  
> 
> However, browsers try to send multiple requests on the same connection if the destination
host is the same.  Therefore what happened is that the browser sent a second request on 54485
(not a new connection!) as a result "connect" is never executed.  Obviously no new ProxyTask
is created in that instance.  Search for this line in the log to see the evidence (lines marked
with ***** are my annotations of the log):
> 
> ***** conn: 54485  received new SECOND request on original client connection
> 
> As you can see "connected" is not executed in this case but it is executed as a result
of requestInput() giving us the new connection (54487).   After the request by 54487, the
Origin then reuses the original connection to Google:80 which was first established from 54485
and still has not been completed,

Rae,

Browsers are not really meant to re-use the connection until the actual 
request / response sequence has been fully completed. The scenario you 
are describing is called HTTP pipelining. I am not aware of any common 
browser applications using it (or at the very least having it enabled 
per default), mainly due to compatibility reasons.

The reverse proxy example was never meant to support the HTTP message 
pipelining.

Hope this explains it

Oleg


  i.e in a REQUEST_SENT state instead of IDLE or CLOSED.
> 
> If you follow it further you then see the inevitable, i.e. the Illegal target connection
state: REQUEST_SENT.
> 
>> Also consider contributing ;-)
> 
> I will, given time and resources. :)
> 
> Rae
> 
> ---------------------------------------------------------------------
> 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