Sun Java System Web Server 7.0 Update 2 Administrator's Configuration File Reference


The following table describes parameters for the check-request-limits function.

Table 7–17 check-request-limits Parameters




(Optional) Threshold for matching requests per second. If this threshold is exceeded subsequent connections matching the criteria are not serviced. Because an acceptable threshold value can vary widely between sites, there is no default value for this parameter.  


(Optional) Maximum number of concurrent matching connections. If the server receives a request that matches the criteria while the number of matching requests currently being processed meets or exceeds this number, the request is denied.  

Note that this number is the current requests at any time, and is independent of the interval. parameter. As soon as the number of concurrent requests falls below this limit, new matching requests are processed.

Because an acceptable value can vary widely between sites, there is no default value for this parameter. 


(Optional) In seconds, the time interval during which average requests per second is computed. The max-rps limit is not applied until the next request rate computation. Because potential attackers can have unlimited requests serviced during this interval, balance the length of this interval against the performance cost of recomputing the maximum requests per second. The default is 30 seconds.


(Optional) Determines what condition must be met in order for a blocked request type to become available again for servicing.  

Valid values are:

  • silence – Refused requests must fall to zero in a subsequent interval for service to resume.

  • threshold – Refused requests must fall below the max-rps value for service to resume.

The default value is threshold.


(Optional) The HTTP status code to use for blocked requests. The default value is 503 (the Service Unavailable error).


(Optional) A request attribute to monitor. Request rates are tracked in a bucket named by the value of this parameter. If the monitor parameter is not specified, the matching requests are tracked in an unnamed (anonymous) bucket. Note that these buckets are different from the buckets you specify with the standard obj.conf bucket parameter.

Although the value of the monitor parameter can be a fixed string, it is most useful when you use predefined variables, for example, monitor="$ip". You can also specify multiple variables, separated by a colon. For example, monitor="$ip:$uri". For a list of predefined variables, see Predefined Variables.



(Optional) Common to all obj.conf functions. Adds a bucket to monitor performance. For more information, see The bucket Parameter.