The headers of a proxied page do not contain a keep-alive or connection headers, but the server acts according to its local keepalive timeout and max count, but the client-browser needs to guess, wether the server supports keep-alive. Setup: ./configure --enable-proxy --enable-proxy-http Config: ProxyPass /proxy/ http://httpd.apache.org/ Testcase: #telnet localhost 80 GET /proxy/robots.txt HTTP/1.1 Host: httpd.apache.org Connection: keep-alive User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;) The response neither contains a Connection: nor a Keep-alive: header. However the connection remains open for 5 seconds and is then "closed by the foreign host". A "GET / HTTP/1.1" returns: Keep-Alive: timeout=5, max=100 Connection: Keep-Alive talking directly to the remote server also returns these values, they only get lost passing the proxy. (this also happens when configured as forward proxy) BTW: a "connection: close" request header makes its way through to the backend server, which causes the connection between front and backend server to be dropped. When used to accelerate a backend server this prevents the connection from being reused for another client or the next request.
Created attachment 17619 [details] Patch against trunk I had a look in this issue and have an idea why this happens. I still need some discussion for this patch on the dev list, but I would like to know if it fixes your problem. So could you please try the attached patch and check if it solves the problem?
thanks for the quick patch, it works for me. However you also need to get rid of line 616 which already clears the connection header from the headers_in.
(In reply to comment #2) > thanks for the quick patch, it works for me. However you also need to get rid of > line 616 which already clears the connection header from the headers_in. Thanks for the quick test. I think you mean line 620, don't you? Alas! Stupid copy and paste error. Thanks for pointing it out. I will discuss the patch on the dev list and keep you in the loop.
Next stupid thing of mine: Of course its 616 in the patched version, but 620 in the unpatched one :-).
I really should RTFM of patch and diff, so line numbers and order of fileargs wouldn't be a problem ... 2 things I'm wondering as code novice about: does the copied table get freed and wouldn't it be better to just save the removed headers ? (P.S: patch isnt't in productive environment yet, so we don't know of possible side-effects)
(In reply to comment #5) > I really should RTFM of patch and diff, so line numbers and order of fileargs > wouldn't be a problem ... I should have looked at the patched version :-). > > 2 things I'm wondering as code novice about: does the copied table get freed and Yes, because the space is allocated from a memory pool and this pool is cleaned after the end of the request. > wouldn't it be better to just save the removed headers ? (P.S: patch isnt't in > productive environment yet, so we don't know of possible side-effects) In principle yes, especially if the other headers are large. I have to take a look into it whether the extra effort of doing so is justified, because several headers are removed by ap_proxy_clear_connection and it adds some work to save them and merge them back in. The full copy approach has a simpler logic and if possible I like to keep things simple :-)
(In reply to comment #6) > > > wouldn't it be better to just save the removed headers ? (P.S: patch isnt't in > > productive environment yet, so we don't know of possible side-effects) Meanwhile I had a closer look into this and as apr_table_copy only copies the pointers to the key / value pairs of the headers I guess we neither gain much speed (actually I think we will loose speed for a small number of headers) nor save a reasonable amount of memory (also guess that we waste memory for a low number of headers) by only saving the removed headers and mergíng them back in later on. I keep you updated.
I committed two patches to the trunk (r377053 and r377057, http://svn.apache.org/viewcvs.cgi?rev=377053&view=rev, http://svn.apache.org/viewcvs.cgi?rev=377057&view=rev). r377053 fixes the problem with the missing keepalive headers in the response, wheras r377055 prevents the closing of the backend connection if the client send Connection: close.
http://svn.apache.org/viewcvs.cgi?rev=377053&view=rev introduced a pool memory problem since I used the wrong pool for apr_table_copy. http://svn.apache.org/viewcvs.cgi?rev=377525&view=rev should fix this, but I am waiting for confirmation by other developers. I keep you updated.
It has been confirmed that http://svn.apache.org/viewcvs.cgi?rev=377525&view=rev fixes the pool memory problem. So could you please test with both patches applied and let me know the results? Many thanks.
we are running the patches productive, keepalive headers are correctly exchanged between browser and frontend apache (mod_proxy). Backend Connections remain open as far as the backends keep alive settings permits it. No memory problems noticed. Good work. Thanks.
We were experiencing the same problem for our reverse proxy (v2.0) and therefore updated to version 2.2.2 that included this patch. For testing and debugging purposes we used HTTP connections to our backend (a webdispatcher). Client <--https--> Apache2.2.2 as Reverse Proxy <--http--> Dispatcher <--http--> App Server For production we need a HTTPS connection to this webdispatcher. Client <--https--> Apache2.2.2 as Reverse Proxy <--httpS--> Dispatcher <--http--> App Server When using this setup (mod_proxy + mod_ssl), we're experiencing a lot more connections in contrast to the setup without mod_ssl. Since I cannot sniff on these HTTPS connections, I cannot provide you with any logs. Has anyone experienced the same problem? Any suggestions?
From mod_proxy_http.c Apache 2.2.2 /* * TODO: Currently we cannot handle persistent SSL backend connections, * because we recreate backend->connection for each request and thus * try to initialize an already existing SSL connection. This does * not work. */ if (is_ssl) backend->close_on_recycle = 1; (In reply to comment #12) > We were experiencing the same problem for our reverse proxy (v2.0) and therefore > updated to version 2.2.2 that included this patch. > For testing and debugging purposes we used HTTP connections to our backend (a > webdispatcher). > Client <--https--> Apache2.2.2 as Reverse Proxy <--http--> Dispatcher <--http--> > App Server > > For production we need a HTTPS connection to this webdispatcher. > Client <--https--> Apache2.2.2 as Reverse Proxy <--httpS--> Dispatcher > <--http--> App Server > > When using this setup (mod_proxy + mod_ssl), we're experiencing a lot more > connections in contrast to the setup without mod_ssl. > Since I cannot sniff on these HTTPS connections, I cannot provide you with any logs. > > Has anyone experienced the same problem? Any suggestions? (In reply to comment #12) > We were experiencing the same problem for our reverse proxy (v2.0) and therefore > updated to version 2.2.2 that included this patch. > For testing and debugging purposes we used HTTP connections to our backend (a > webdispatcher). > Client <--https--> Apache2.2.2 as Reverse Proxy <--http--> Dispatcher <--http--> > App Server > > For production we need a HTTPS connection to this webdispatcher. > Client <--https--> Apache2.2.2 as Reverse Proxy <--httpS--> Dispatcher > <--http--> App Server > > When using this setup (mod_proxy + mod_ssl), we're experiencing a lot more > connections in contrast to the setup without mod_ssl. > Since I cannot sniff on these HTTPS connections, I cannot provide you with any logs. > > Has anyone experienced the same problem? Any suggestions? (In reply to comment #12) > We were experiencing the same problem for our reverse proxy (v2.0) and therefore > updated to version 2.2.2 that included this patch. > For testing and debugging purposes we used HTTP connections to our backend (a > webdispatcher). > Client <--https--> Apache2.2.2 as Reverse Proxy <--http--> Dispatcher <--http--> > App Server > > For production we need a HTTPS connection to this webdispatcher. > Client <--https--> Apache2.2.2 as Reverse Proxy <--httpS--> Dispatcher > <--http--> App Server > > When using this setup (mod_proxy + mod_ssl), we're experiencing a lot more > connections in contrast to the setup without mod_ssl. > Since I cannot sniff on these HTTPS connections, I cannot provide you with any logs. > > Has anyone experienced the same problem? Any suggestions?