Antw: TCP SYN behavior and reverse proxy

Hello, don't know if this works or if you tried it already but here are =
some Environment Variables which could help.
proxy-sendchunks or proxy-sendchunked or maybe proxy-initial-not-pooled.
I changed the keep-alive timeout on the backend to the timeout of the =
frontend apache to minimize the "502 Bad Gateway" error.

Michael

>>> Prigge Scott 11.11.09 18.45 Uhr >>>
Hi. I'm running 2.2.8 on Linux with mod_proxy in a reverse proxy configurat=
ion, which is forwarding data to an application server. And there is a =
feature within this application which relies on HTTP POST data from the =
browser. We also have a third-party authentication module which is loaded =
as a shared object. When the authentication shared object not loaded in =
Apache, the HTTP POST data is spooled to the application server as it is =
being received. But when the auth shared object is loaded, the HTTP POST =
data is held until all of it is received from the browser.=20

I can see in network traces that in both cases, Apache opens a new TCP =
connection with the application server immediately after the initial TCP =
connection with the browser is established. But over slow WAN connections =
for example, it takes a number of minutes to receive all of the POST data. =
And since Apache initiates a new TCP connection with the app server =
immediately, the TCP connection with the app server remains idle for a =
number of minutes. When Apache eventually does receive all of the POST =
data and begins forwarding it to the application server, the OS on the app =
server has timed out the TCP connection and responds with TCP RST packets. =
As a result, the browser receives a "502 Bad Gateway" response.

Is there a way I might force Apache or (mod_proxy) to wait until all of =
the HTTP POST data is received before establishing a new TCP connection =
with the app server? I have tried adding a number of Apache/mod_proxy/mod_p=
roxy_http directives in various combinations, but haven't been able to =
change this specific behavior.



------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org





------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

RE: TCP SYN behavior and reverse proxy (mod_proxy)

> Hello, don't know if this works or if you tried it already but here are s=
ome Environment Variables which could help.
> proxy-sendchunks or proxy-sendchunked or maybe proxy-initial-not-pooled.
> I changed the keep-alive timeout on the backend to the timeout of the fro=
ntend apache to minimize the "502 Bad Gateway" error.

Hi, thanks for your thoughts Michael. In fact, I have tried proxy-sendchunk=
ed. It seems to cause Apache to spool the POST data as it is being received=
- and that's great. Unfortunately the app can't handle chunked encoding, s=
o that option is out. I've also tried proxy-initial-not-pooled, force-proxy=
-request-1.0, proxy-nokeepalive, and some others without any noticeable eff=
ect. Maybe I just haven't stumbled across the correct combination, though I=
am starting to suspect there is none.

I can understand what you are saying regarding the Keep-Alive timeout value=
.. However the timeout threshold we are reaching is being imposed by the OS =
(Linux in this case), not by Apache. I know this because while the TCP conn=
ection with the app server is waiting for the POST data to be received, the=
app server is sending multiple SYN-ACKs in an attempt to get something fro=
m the webserver. There is an TCP kernel parameter you can adjust (sysctl -w=
net.ipv4.tcp_synack_retries=3D5) which controls how many TCP SYN-ACKs that=
will be sent during these conditions. And if I bump this number up, it cau=
ses the OS to keep the idle TCP connection open longer and the POST complet=
es successfully.

But...that's just a workaround in my opinion. What I really want is for Apa=
che to wait until it receives all of the POST data before it opens the TCP =
connection to the app server.


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org