On Tuesday 01 September 2009, Torsten Foertsch wrote: > Just a few thoughts: > > - You use GLOBAL_ONLY in ap_check_cmd_context. That means the > directive must not appear in vhost context. AFAIK, > conn->base_server reflects the vhost in a pre connection hook if it > is IP-based. So, why don't you allow for RequestTimeout to be valid > in ip-based vhost context?
Basically because I didn't get around to write the merge function yet. But it's on my todo list. > That way the protocol problem is solved, > isn't it? That's true. It's probably not necessary to detect non-http virtual hosts automatically. Just let the admin configure it. > - Wouldn't RequestTimeout better be named RequestHeaderTimeout or > ReadRequestHeaderTimeout? RequestTimeout is a bit missleading > (IMHO). My first thought was: That thing limits the whole > transaction. Maybe. I will think about this. > > - You mentioned a minimum body transfer rate instead of a simple > timeout. If the default values for LimitRequestFields, > LimitRequestFieldSize and LimitRequestLine are added up I get a > max. request header size of 101*8190 bytes. This may take some time > to transmit while still valid. So, perhaps a transfer rate limit > for the header is a good option, as well. Perhaps having both a > timeout and a rate limit would be good. A more realistic estimate for the maximum for a valid request is 10*8190 + 91*100, i.e. there are normally only very vew long lines. But if the transfer rate function is added for the body, it's easy to add it for the headers, too.
