Hi, Jeremy. > I looked at the page you mentioned below. It wasn't really > clear on the page, but what happens when the requests get above > the max allowed? Are the remaining requests queued or are they > simply given some kind of error message?
The service will respond with an HTTP 503 message when the MaxConcurrentReqs number is reached. That tells the browser that the service is temporarily unavailable and to try again later. > There seem to be a number of different modules for this kind of > thing, but most of them seem to be fairly old. We could use a > more currently throttling module that combines what others have > come up with. Age shouldn't matter. If something works as designed, it doesn't need to be updated. :) > For example, the snert.com mod_throttle is nice because it does > it based on IP - but it does it site wide in that mode. This > mod_throttle seems nice because it can be set for an individual > URI...But that's a pain for sites like mine that have 50 or > more intensive scripts (by directory would be nice). And still > both of these approaches don't use cookies like some of the > others to make sure that legit proxies aren't blocked. Well, the design goals of each are probably different. For instance, mod_throttle_access was designed to keep a service healthy, not punish a set of over-zealous users. Blocking by IP doesn't necessarily protect the health of your service. Also, you shouldn't rely on cookies to ensure the health of your service. If someone has cookies disabled, they can defeat your scheme. BTW, mod_throttle_access is a per-directory module (ie, by <Directory>, <Location>, or <Files>), so you can protect an entire tree at once. It will just count that entire tree as one unit during its count toward MaxConcurrentReqs. Regards, Christian ----------------- Christian Gilmore Technology Leader GeT WW Global Applications Development IBM Software Group
