I am seeing some odd behaviour with mod_reqtimeout, and have a couple
of questions on its internals (apache2-mpm-prefork 2.2.14-5ubuntu8.9)
Q1. I have an environment which is doing this (in essence):
RequestReadTimeout header=10-20,minrate=500
RequestReadTimeout body=10,minrate=500
NameVirtualHost 192.200.0.1:80
... uninteresting default virtual host...
<VirtualHost 192.200.0.1:80>
ServerName a.example.com
RequestReadTimeout header=0 body=0
... stuff ...
</VirtualHost>
RequestReadTimeout on the VirtualHost does not override RequestReadTimeout
at a global level. I still see mod_reqtimeout closing the socket to
long lasting requests on this virtual host. Disabling at the global
level works fine. Have I misunderstood how this is meant to work?
Q2. Sadly, disabling it at the global level isn't really enough for me.
What I am doing is using self.disconnect's apache modwebsockets code.
The sessions it uses are long lasting. Running without SSL (we seem
to have fewer problems with SSL) we see disconnects even with parameters
like this:
RequestReadTimeout body=300,minrate=1
As far as I can tell, that means every 1 byte it should increase the
timeout by 1, from 300 up to infinity. But after sometimes as little
as 10 seconds, we see a timeout. There is far more traffic than this
passing (we're sending a websockets ping every couple of seconds)
How does mod_reqtimeout monitor the presence of traffic? I'm using
ap_get_brigade to read data, and ap_fwrite/ap_fflush to write data
back. It's almost as if it's not seeing the data at all (it appears
to be better on ssl).
What I'd really like to do is just turn off mod_reqtimeout when the
websockets connection is active, as at that point I'm doing my own
idle checking. Can I somehow call into mod_reqtimeout and modify
the parameters on the request and tell it to stop whatever it's
doing?
--
Alex Bligh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|