httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: OS Keep-alive on forward proxy
Date Thu, 05 Aug 2010 15:55:59 GMT
In adition to Rüdiger's reply:

On 05.08.2010 17:31, Paul Fee wrote:
> "Plüm, Rüdiger, VF-Group" wrote:
>>> -----Original Message-----
>>> From: Paul Fee
>>> Sent: Donnerstag, 5. August 2010 11:18
>>> To: dev@httpd.apache.org
>>> Subject: Re: OS Keep-alive on forward proxy
>>>
>>> Rainer Jung wrote:
>>>
>>> <snip>
>>>
>>>> And yes: the forward proxy does *not* do HTTP Keepalive. Technical
>>>> reason: the connections to the origin server are pooled and
>>> retrieved
>>>> from and returned to the pool for each request. A forward
>>> proxy usually
>>>> talks to many diferent origin servers. Keeping those
>>> connections open in
>>>> a naive way would lead to a lot of not well used pools.
>>> Assuming that
>>>> during one client connection the origin server often is used for
>>>> multiple requests this could be improved, but would bloat
>>> the already
>>>> complicated proxy code even more.
>>>
>>> Has mod_proxy operated in that way for a while now?  I gained
>>
>> Since 2.2.
>>
>>> most of my
>>> experience with mod_proxy using Apache 2.0.X.  My
>>> understanding was that
>>> proxy to OS connections were tightly coupled to the client to proxy
>>
>> That was true in 2.0.x yes.
>>
>>> connection.  There was a deliberate decision not to reuse proxy->OS
>>> connections for requests coming from other client->proxy
>>> connections as this
>>> may be a security risk.
>>>
>>> The OS may attribute authorization to a connection and a
>>> subsequent request
>>> on this persistent connection could inherit these attributes.
>>>   Each HTTP
>>> request *should* be stateless and hence the next request on
>>> the same socket
>>> should be independent, but there was the risk that a remote
>>> (non-Apache)
>>> origin server may not work that way.  If the proxy->OS
>>> connection is pooled
>>> and reused by a different client->proxy request, does that
>>> risk confusing an
>>> origin server that expects all requests on the same
>>> connection to come from
>>> the same client?
>>
>> It would be a bug in this server to expect them to origin from the
>> same client as you correctly state that HTTP is a stateless protocol.
>> Nevertheless you can turn off connection pooling in the case you
>> are dealing with a faulty origin server.
>>
>> Regards
>>
>> Rüdiger
>
> That's useful information, it's not mentioned in the overview of new
> features in 2.2 and I missed it in the detailed changelog.  Thanks for
> correcting my misunderstanding.
>
> Regarding disabling connection pooling, I looked at the source and see two
> ways to achieve this:
>
> 1) The "disablereuse" parameter of the ProxyPass directive.
> 2) The "proxy-initial-not-pooled" Apache environment variable set on a per-
> request basis.
>
> Both these relate to reverse proxy requests.
>
> Does connection pooling apply to forward proxy requests?  If so, are there
> configuration options to control it?
>
> Would disabling connection pooling fix the defect that Ryujiro Shibuya
> reported (with the penalty of losing the performance gains for pooling)?

The default worker for forward proxying does not use connection pooling 
in the naive sense. It closes each connection after each request.

What Ryujiro Shibuya was observing was that Apache signals it would keep 
the connection open even in forward proxy mode, but then acually closes 
the connection. We are discussing a fix to this, namely always 
signalling "Connection: close" from the beginning for the default 
forward and revere proxy workers.

You can define explicit workers though (e.g. using ProxyPass for reverse 
and as Rüdiger wrote likely also in forward proxy mode, which then will 
use HTTP Keep-Alive (by default, depending on several config options).

I just started to scribble an addition to the mod_proxy docs to explain 
a bit more about the concept of workers. Let's see how far this gets.

Regards,

Rainer

Mime
View raw message