On Jan 20, 2009, at 2:48 PM, John ORourke wrote:
Hi there,I couldn't find the answer to this in various user docs/forums/etc, apologies if it's a simple thing.I have a particularly busy URI on a particular VirtualHost and I'd like to limit how many clients can request that URL at a time. I've been looking for things like being able to use MaxClients inside a <Location>.I don't know where in the server/request life cycle the connection gets handed off to a child process, but I guess it'll be before the request is read in - if so we're probably not going to be able to do this. The requests are large POST requests, so we'd need to read the request headers before allocating a child process, we can't just rewrite the request.
The child processes inherit an open file descriptor for each listener configured. The parent (running as root) attaches to the socket, which may be on a privileged port. The children (which change uid) call accept() on the existing open file descriptors.
Hence, the children perform the complete request processing cycle, from accepting the connections to reading the request headers, AAA assessment and enforcement, reading the request body, processing the requests to generating and writing the response.
The first time you learn of a request is after the TCP socket has been accept()ed, but unless you use IP based virtual hosts exclusively the first time you can enforce resource use is after the request headers are read. You would be using some kind of shared memory buffer to keep track of how many children are serving a particular vhost, or perhaps you can leverage the scoreboard.
My 'plan B' is to run another httpd on a different port to handle these requests - I have control of the clients so can change the URI. That's actually sounding like a much simpler solution now!
Or you use a single httpd with mod_proxy to ProxyPass and ProxyPassReverse to the individual vhosts. But you better make sure that mod_proxy does something your clients can deal with: it'll throw you 504 responses if it can't connect to the backend.
S. -- Sander Temme [email protected] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME cryptographic signature
