|  | 
 
More information about mod_qos:
 
 Build
mod_qos requires OpenSSL, PCRE, threading and shared memory support. 
mod_qos is designed to be used with Apache's
MPM worker  binaries but works, with some restrictions, also with other Apache 2.4 multi-processing modules.
The module is optimized to be used in a 
reverse proxy  server. 
 
Notes:You should choose the worker MPM
  if you intend to use any connection level control directive. If you decide to use HTTP/2
  , 
you should only use the request level control directives  
as mod_qos works for the hypertext transfer protocol
version 1.0 and 1.1 (RFC1945/RFC2616) only. 
You can compile the module using 
apxs . 
Your httpd binary must support dynamically loaded objects 
(DSO). Verify this by checking the availability of mod_so: The commandhttpd -lmust list the mod_so.c module. 
The following command compiles the module and installs mod_qos into the 
server's modules directory. 
If the necessary header files of OpenSSL, PCRE, etc. cannot be found, add 
the| 
cd mod_qos-11.76/apache2
apxs -i -c mod_qos.c -lcrypto -lpcre2-8
cd ../..
 |  -Ioption to theapxscommand to specify 
the directory where header files can be found and if any of the required 
libraries cannot be found (may happen if you use mod_qos without mod_ssl), 
add the-Loption to specify the directory where libraries 
can be found.Note: you may customize the code using the following preprocessor directives:
 
 |  | Name | Description | Default |  
 |  | QS_MOD_EXT_HOOKS | Enables the optional hooks defined in mod_qos.h | not set |  
 |  | QSLOG_CLID | Defines the environment variable which shall be used for the "user tracking id" (U)
within the format string used by the QSLogdirective. | mod_qos_user_id |  
 |  | QSLOG_EVENT | Defines the environment variable which shall be used for the "event" (Q)
within the format string used by the QSLogdirective. | Event |  
 |  | QSLOG_AVERAGE | Defines the environment variable which shall be used for the "average" (a)
within the format string used by the QSLogdirective. | QS_AllConn |  
 |  | QS_LOG_REPEAT | Counter used to define how many repetitive messages are summarized. | 20 |  
 |  | QS_REQ_RATE_TM | Default for the QS_SrvSampleRatedirective. | 5 |  
 |  | QS_EXTRA_MATCH_LIMIT | Match limit field used for PCRE data processing. | 1500 |  
The support tools may be built (at least on some 
Linux platforms) using the GNU autotools. Some of these 
utilities require third-party libraries such as apr, apr-util, PCRE2, 
and OpenSSL.
 
| 
cd mod_qos-11.76/tools
./configure
make
 |  Source Code
mod_qos is available for Apache version 2.4.
 ConfigurationConfiguration is mostly done on a per-server basis (except the 
generic request filter and a few other directives). 
Directives within a virtual 
host are merged with the settings in the global configuration.
 
The QS_SrvMinDataRate,QS_SrvRequestRate,QS_RequestHeaderFilterRule,QS_ResponseHeaderFilterRule, 
and allQS_Client*directives may be used outside of virtual host configurations only. 
The QS_LogOnly ondirective may be used to put mod_qos 
into a permissive mode where rule violations are logged only but 
requests/connections are not blocked. This may be used for test purposes.Should not be activated if you are using any 
throughput control 
directive (open loop).
 
 Request Level ControlThe module features directives to control server access 
on a per-URL level - basically the main function of mod_qos.Only one
 QS_Loc*rule (URL string or 
regular expression) of each type is evaluated per request where 
regular expression rules (*Match) have higher priority 
than the rules using a literal URL-string. AQS_LocRequestLimit*rule may be used in parallel to aQS_LocRequestPerSecLimit*and/orQS_LocKBytesPerSecLimit*rule if they use the very 
same URL string or regular expression.
QS_LocRequestLimitMatch <regex> <number>Defines the number of concurrent 
requests for the specified request pattern (path and query). 
The rule with the lowest number of allowed concurrent connections has the 
highest priority if multiple expressions match the request. 
By default, no limitations are active.
QS_LocRequestPerSecLimitMatch <regex> <number>Defines the allowed number of requests per second
to the URL (path and query) pattern. Requests are limited by
adding a delay to each request (linear). The delay calculation is based on
an average request rate measurement using a sampling rate of 10 seconds. 
By default, no limitation is active. This directive should be used in 
conjunction with
 QS_LocRequestLimitMatchonly (you must use the very same regex pattern with theQS_LocRequestPerSecLimitMatchandQS_LocRequestLimitMatchdirective) to avoid too many concurrent requests.
QS_LocKBytesPerSecLimitMatch <regex> <number>Defines the allowed download bandwidth to the location
matching the defined URL (path and query) pattern. Responses are slowed down by 
adding a delay to each response (every 8kbytes). Bandwidth calculation 
is based on measuring the transferred data.
By default, no limitation is active. This directive should be used 
in conjunction with
 QS_LocRequestLimitMatchonly (you must use the very same regex pattern with theQS_LocKBytesPerSecLimitMatchandQS_LocRequestLimitMatchdirective) 
to avoid too many concurrent requests.
QS_LocRequestLimit <location> <number>Defines the number of concurrent 
requests for the specified location (applied to the parsed path). 
By default, no limitations are active for locations. Has lower priority than
 QS_LocRequestLimitMatchdirectives.
QS_LocRequestLimitDefault <number>Defines the 
default limitation for the maximum of concurrent requests per-location 
for those locations not defined by any
 QS_LocRequestLimitdirective. It could also be used to limit the number of concurrent 
requests to a virtual host.
QS_LocRequestPerSecLimit <location> <number>Defines the allowed number of requests per second
to a location, similar to the
 QS_LocRequestPerSecLimitMatchdirective. The maximum number of requests is limited by adding a delay to 
each request (linear, each request gets the same delay). By default, 
no limitation is active.
This directive should be used in conjunction withQS_LocRequestLimitonly (you 
must use the same location for both directives) to avoid too many 
concurrent requests.. Has lower priority thanQS_LocRequestPerSecLimitMatch.
QS_LocKBytesPerSecLimit <location> <number>Throttles the download bandwidth to the defined
kbytes per second. Works similar as the
 QS_LocKBytesPerSecLimitMatchdirective slowing down HTTP responses by adding a delay to each response. 
By default, no limitation is active. This directive should be used in 
conjunction withQS_LocRequestLimitonly 
(you must use the same location for both directives) to avoid too many 
concurrent requests.. Has lower priority thanQS_LocKBytesPerSecLimitMatch. 
| Sample configuration: 
 
# maximum number of active TCP connections is limited to 512
MaxClients                    512
# limits concurrent requests to the locations:
# - /app/a  max. 200 concurrent requests
# - /app/b and /app/c (together) max. 300 concurrent requests
# - /images max. 100 concurrent requests
QS_LocRequestLimit            /app/a                   200
QS_LocRequestLimitMatch       ^(/app/b/|/app/c/).*$    300
QS_LocRequestLimit            /images                  100
# limits download bandwidth to 5Mbit/sec (resp. 640kbytes/sec)
# for downloads from /app/a:
QS_LocKBytesPerSecLimit       /app/a                   640
 |  
 Status Code and Error PageTheQS_Error*directives are used to control the response 
given to clients whose requests have been denied.
QS_ErrorPage <URL>Defines an error page to be 
returned when a request is denied. The defined URL must be a (S)HTML 
document accessible by the client. 
You may enable server-side includes (SSI) 
in order to present detailed error messages based on the 
error codes provided by mod_qos.
 Alternatively, a HTTP redirect (302) to a dedicated error page may be 
defined using an absolute URL defining schema, hostname, and path.
QS_ErrorResponseCode <code>Defines the HTTP 
response code which is used when a request is denied. Requests denied 
at connection level usually get a HTTP 500 response code (ignoring 
the settings of the
 QS_ErrorResponseCodeandQS_ErrorPagedirectives).Default (no custom error code or page defined) codes are:
 400: if a request has no valid URL.
 403: for requests denied by a
 QS_Deny*,QS_Permit*orQS_RequestHeaderFilterdirective.413: when limiting the max. body data length by the
 QS_LimitRequestBodydirective.500: for requests denied by any other directive.
 
 Privileged UsersAdditional directives are used to identify VIPs (very important persons) 
and to control the session life time and its cookie format. VIP users have 
privileged access and less QoS restrictions than ordinary users.
 VIP information is stored and evaluated at different levels:
 
Directives:
Session: VIP identification is stored using a HTTP 
session cookie. mod_qos starts a new session when detecting a HTTP 
response header (the header name is defined by the 
QS_VipHeaderNamedirective). Alternatively, a new session is started when detecting an 
authenticated user, seeQS_VipUser. 
TheQS_Session*directives are used to set session attributes.
Request: The QS_VipRequestprocess environment may be evaluated by mod_qos rules. This 
variable is set automatically when receiving a valid mod_qos 
session cookie. TheQS_VipRequestvariable may also be set by configuration using aQS_SetEnvIf*orSetEnvIf directive. VIP status lasts for the particular 
request only.
Client IP address: VIP identification may be stored at the server side 
on a per-client IP address basis. 
The QS_VipIPHeaderName,QS_VipHeaderName,QS_VipIPUser, andQS_VipUserdirectives are used 
to define when an IP address should be marked as a VIP user. 
QS_VipHeaderName <header name>[=<regex>] [drop]Defines an HTTP response header which marks a user as a VIP. mod_qos creates 
a session for this user by setting a cookie, e.g., after successful user 
authentication. 
Tests optionally its value against the provided regular expression. 
Specify the action 'drop' if you want mod_qos to remove this 
control header from the HTTP response.
QS_VipIPHeaderName <header name>[=<regex>] [drop]Defines an HTTP response header which marks a client source IP address as 
a VIP. 
Tests optionally its value against the provided regular expression. 
Specify the action 'drop' if you want mod_qos to remove this 
control header from the HTTP response.
QS_VipUserCreates a VIP session for users which have been authenticated by the 
Apache server, e.g., by the standard mod_auth* modules.
It works similar to the
 QS_VipHeaderNamedirective.
QS_VipIPUserMarks a source IP address as a VIP if the user has been authenticated by the 
Apache server, e.g. by the standard mod_auth* modules. It works similar to 
the
 QS_VipIPHeaderNamedirective.
QS_SessionTimeout <seconds>Defines the session life time for a VIP. It is only used for session 
based (cookie) VIP identification (not for IP based). 
Default is 3600 seconds.
QS_SessionCookieName <name>A cookie is used to identify requests coming from a user which has 
been identified as a VIP. This directive defines a custom cookie name 
for the mod_qos session cookie. Default is MODQOS.
QS_SessionCookiePath <path>Defines the cookie path. Default is "/".
QS_SessionKey <string>Secret key used for cookie encryption. This key must be defined 
when using the same session cookie for multiple web servers 
(load balancing) or the sessions should survive a server restart. 
By default, a random key is used which changes every server restart.
 The following table shows if a rules may be deactivated for VIPs:
 
Notes:| QS_ClientEventBlockCount | no |  | QS_ClientEventLimitCount | no |  | QS_ClientEventPerSecLimit | no |  | QS_ClientEventRequestLimit | no |  | QS_ClientPrefer | yes |  | QS_ClientSerialize | no |  | QS_ClientGeoCountryPriv | no |  | QS_CondLocRequestLimitMatch | yes |  | QS_CondEventLimitCount | no |  | QS_CondClientEventLimitCount | no |  | QS_DenyQueryBody | no |  | QS_PermitUriBody | no |  | QS_DenyEvent | no |  | QS_DenyPath | no |  | QS_DenyQuery | no |  | QS_DenyRequestLine | no |  | QS_EventKBytesPerSecLimit | yes |  | QS_EventPerSecLimit | yes |  | QS_EventRequestLimit | no |  | QS_EventLimitCount | no |  | QS_InvalidUrlEncoding | no |  | QS_LimitRequestBody | no |  | QS_LocKBytesPerSecLimit(Match) | yes |  | QS_LocRequestLimit(Match) | yes |  | QS_LocRequestPerSecLimit(Match) | yes |  | QS_MileStone | no |  | QS_RedirectIf | no |  | QS_PermitUri | no |  | QS_RequestHeaderFilter | no |  | QS_ResponseHeaderFilter | no |  | QS_SrvMaxConn | yes |  | QS_SrvMaxConnClose | no |  | QS_SrvMaxConnPerIP | yes* |  | QS_SrvMinDataRate | yes* |  | QS_SrvSerialize | no |  |  |  |  Directives marked by "*" allow you to disable VIP support.
 Event based or conditional rules may evaluate the 
QS_VipRequest and 
QS_IsVipRequest variables to decide 
if the rule should be applied.
 
 VariablesEnvironment variables are used on a per
request level and implement additional control mechanisms. Variables may be set
using the standard Apache module
mod_setenvif or 
mod_setenvifplus  .
See also the QS_SetEnvIf*directives in order to combine multiple 
variables to form new variables interpreted by mod_qos rules.
 These are the variables recognized by mod_qos:
 
Variables set by mod_qos which may be processed by conditional or event based 
rules, e.g.,
QS_ErrorPage=<URL>Defines the error page overriding the setting made by the
 QS_ErrorPagedirective.
QS_VipRequest=yesDisables some restrictions for this request (see privileged Users). 
Requires the definition of a VIP header using the
 QS_VipHeaderNamedirective 
(this activates VIP verification). However, such an event does 
not create a VIP session. The user has the VIP status only for 
a single request.The variable is set by mod_qos when 
receiving a valid VIP session cookie.
QS_KeepAliveTimeout=<seconds>Applies dynamic connection keep-alive settings overriding the Apache
 KeepAliveTimeout directive settings.
QS_MaxKeepAliveRequests=<number>Applies dynamic connection keep-alive settings overriding the Apache
 MaxKeepAliveRequests directive settings.
QS_Timeout=<seconds>Alters the I/O timeout (while reading the request body / writing the response) 
of the current request overriding the Apache
 TimeOut directive settings.
QS_Set_DSCP=<value>Variable used to set the IP differentiated services code points 
(DiffServ / RFC 2474). This allows you to classify the network 
traffic when sending the response data to the client. "value" 
represents the 6-bit DSCP field as a decimal number (0 to 63).
 Commonly used values:
 
| DSCP | Class |  | DSCP | Class |  | 0 | none |  | 8 | Class selector 1 |  | 10 | Assured forwarding 11 |  | 12 | Assured forwarding 12 |  | 14 | Assured forwarding 13 |  | 16 | Class selector 2 |  | 18 | Assured forwarding 21 |  | 20 | Assured forwarding 22 |  | 22 | Assured forwarding 23 |  | 24 | Class selector 3 |  | 26 | Assured forwarding 31 |  | 28 | Assured forwarding 32 |  | 30 | Assured forwarding 33 |  | 32 | Class selector 4 |  | 34 | Assured forwarding 41 |  | 36 | Assured forwarding 42 |  | 38 | Assured forwarding 43 |  | 40 | Class selector 5 |  | 44 | Voice admit |  | 46 | Expedited forwarding |  | 48 | Class selector 6 |  | 56 | Class selector 7 | 
QS_Delay=<milliseconds>Defines a number of milliseconds to delay the request processing.
QS_EventThe variable processed by the
 QS_ClientEventPerSecLimitdirective.
QS_Block[=<number>]Variable processed by the
 QS_ClientEventBlockCountdirective.The optional
 numbervalue defines the penalty points to 
increase the counter (default is 1).
QS_Limit[=<number>](Default) variable processed by the
 QS_ClientEventLimitCountdirective.The optional
 numbervalue defines the penalty points to 
increase the counter (default is 1).
*_ClearThe counter of the variable processed by the
 QS_ClientEventLimitCountdirective  is reset if you set the same variable suffixed by_Clear, 
e.g.QS_Limit_Clear.
*_DecrementThe counter of the variable processed by the
 QS_EventLimitCount,QS_CondEventLimitCount,QS_ClientEventLimitCount,QS_CondClientEventLimitCount, andQS_ClientEventBlockCountdirectives 
is decremented by the value set in the same variable suffixed by_Decrement, 
e.g.QS_Limit_Decrement=1decrements the value of theQS_Limitvariable of the correspondingQS_ClientEventLimitCountrule by 1. The variable is evaluated at the end of the request processing.
QS_SerializeVariable processed by the
 QS_ClientSerializedirective.
QS_SrvSerializeVariable processed by the
 QS_SrvSerializedirective.
QS_CondVariable processed by the
 QS_CondLocRequestLimitMatch,QS_CondEventLimitCount, andQS_CondClientEventLimitCountdirectives.
QS_EventRequestVariable processed by the
 QS_ClientEventRequestLimitdirective. QS_CondLocRequestLimitMatch:
QS_SrvConnNumber of concurrent 
connections for this server/virtual host. Value is set 
when using either the
 QS_SrvMaxConn,QS_SrvMinDataRate,QS_SrvMaxConnClose, orQS_ClientGeoCountryDBdirective.Note: value is calulcated when the client establishes the connection 
and remains the same for all HTTP requests performed on this connection.
QS_AllConnNumber of all concurrent connections for this Apache instance. Value is set 
when using either the
 QS_SrvMaxConn,QS_SrvMinDataRate,QS_SrvMaxConnClose, orQS_ClientGeoCountryDBdirective.Note: value is calulcated when the client establishes the connection 
and remains the same for all HTTP requests performed on this connection.
QS_IPConnNumber of IP connections open from the current IP address. Variable is 
available when using the
 QS_SrvMaxConnPerIPdirective.Note: value is calulcated when the client establishes the connection 
and remains the same for all HTTP requests performed on this connection.
QS_ClientLowPrioThe variable is set for connections by clients which have been marked to be 
processed with low priority, see
 QS_ClientPrefer. 
The variable's value is determined when the client opens a new connection and 
its value represents the status flag of the tracked client attributes 
(hexadecimal). VIP status is ignored and
the variable is always set even the IP has been marked as being VIP.
QS_IsVipRequestVariable is set when detecting a VIP request
(either by cookie, IP address status, valid user, etc.). May be used by
various event based directives.
*_CounterThe counter values of the variables used by the
 QS_ClientEventLimitCountandQS_EventLimitCountdirective are stored within the variable whose name is suffixed by_Counter, e.g.QS_Limit_Counterwhen limitingQS_Limitevents.
QS_ErrorNotesThe error code (number only) of a mod_qos log message 
that has occurred during a request.
QS_CountryISO 3166 country code of client IPv4 address. Only available if the 
geographical database file has been loaded.
 
 
Note: The| Sample of variable usage: 
 
# privileged access for curl clients:
BrowserMatch             "curl"                   QS_VipRequest=yes
# allows privileged access to a single resource:
SetEnvIf     Request_URI /app/start.html          QS_VipRequest=yes
# allows privileged access from a specified source address
# or source address range:
SetEnvIf     Remote_Addr 172.18.3.32              QS_VipRequest=yes
SetEnvIf     Remote_Addr 192.168.10.              QS_VipRequest=yes
# set keep-alive timeout for MSIE version 5.x browser to 65 seconds:
BrowserMatch             "(MSIE 5\.)"             QS_KeepAliveTimeout=65
# dynamic error page URL (per host error page):
SetEnvIf     Host        ^([a-zA-Z0-9_\.\-]+)     QS_ErrorPage=/error-docs/$1.html
# external redirect to a sever hosting the error page:
SetEnvIf     Request_URI /app                     QS_ErrorPage=http://your.server.name/error.html
 |  QS_LogEnvdirective can be used to enable environment variable logging. mod_qos 
writes all environment variables which are set when entering a handler 
to the log.
 Conditional RulesConditional rules are only enforced if theQS_Condvariable matches the specified pattern.
QS_CondLocRequestLimitMatch <regex> <number> <condition>Rule works similar to
 QS_LocRequestLimitMatchbut it is only enforced for requests whoseQS_Condvariable matches the specified condition (regular expression). Every request 
matching the defined pattern is counted, but the defined limitation is only 
enforced for those requests matching the specified condition.Only one
 QS_CondLocRequestLimitMatchrule is evaluated per request.
QS_CondEventLimitCount <env-variable> <number> <seconds> <pattern>Same as
 QS_EventLimitCountbut
requests are only blocked if the value of theQS_Condvariable matches the defined pattern (regex).
QS_CondClientEventLimitCount <number> <seconds> <variable> <pattern>Defines the maximum number of the specified environment variable
allowed within the defined time. Directive works similar as
 QS_ClientEventLimitCountbut requests are only blocked if the value of theQS_Condvariable matches the defined pattern (regex). Directive is allowed 
in global server context only.
 
| Sample of conditional rules: 
 
# set the conditional variable to spider if detecting a
# "slurp" or "googlebot" search engine:
BrowserMatch             "slurp"                  QS_Cond=spider
BrowserMatch             "googlebot"              QS_Cond=spider
# limits the number of concurrent requests to two applications
# (/app/b and /app/c) to 300 but does not allow access by a "spider"
# if the number of concurrent requests exceeds the limit of 10:
QS_LocRequestLimitMatch       "^(/app/b/|/app/c/).*$"  300
QS_CondLocRequestLimitMatch   "^(/app/b/|/app/c/).*$"  10   spider
 |  Eventsmod_qos may control the frequency of "events". An event may be any 
request attribute which can be represented by an
environment variable. 
Such variables may be set by 
mod_setenvif , 
mod_setenvifplus  , or 
by other Apache modules.
Please consider the order of command execution 
to ensure that the necessary variables are set. 
Mulpiple built-in directives may be used to set or detect events (additional
event variable processing could be configured using
mod_setenvif
QS_EventRequestLimit <env-variable>[=<regex>] <number>Defines the number of concurrent events. 
Directive works similar to
 QS_LocRequestLimit, but 
counts the requests having the same environment variable (and optionally 
matching its value, too) rather than those that have the same URL pattern.Note: The counter's value is stored in the environment variable 
QS_EventRequestLimit_<env-variable>_Counter.
QS_EventPerSecLimit [!]<env-variable> <number>Defines how often requests may have the defined environment variable 
(literal string) set. It measures the occurrences of the defined 
environment variable on a request per seconds
level and tries to limit this occurrence to the defined number. It works similar as
 QS_LocRequestPerSecLimit, 
but counts only the requests with the specified variable (or without it
if the variable name is prefixed by a "!"). If a request matches 
multiple events, the rule with the lowest bandwidth is applied. 
Events are limited by adding a delay to each request causing an 
event.
QS_EventKBytesPerSecLimit [!]<env-variable> <number>Throttles the download bandwidth
of all requests having the defined variable set to the defined
kbytes per second. Responses are slowed by adding a delay to each
response (every 8kbytes). The delay calculation 
is based on an average request rate measurement.
By default, no limitation is active. 
This directive should be used in conjunction with
 QS_EventRequestLimitonly (you must use the same variable name for both directives) to avoid too many 
concurrent requests.
QS_EventLimitCount <env-variable> <number> <seconds>Defines the maximum number of events allowed within the defined time. 
Requests causing the event are denied when reaching this limitation for the specified time 
(blocked at request level).
 Notes:
 
The current counter value is propagated to the process environment within 
the variable <env-variable>_Counter.See also QS_CondEventLimitCountif you want to enforce a rule under certain conditions only.The event counter can be decremented by setting the environment 
<env-variable>_Decrement.  or 
mod_setenvifplus  ). 
QS_SetEnvIf [!]<env-variable1> [!]<env-variable2> [!]<env-variable=value>Sets (or unsets) the environment "variable=value" (literal string) if variable1 (literal 
string) AND variable2 (literal string) are set in the request environment 
variable list (not case sensitive). This is used to combine multiple 
variables to a new event type.
 This directive may be used on a per-server or
location
  basis.
QS_SetEnvIf <env-variable1>=<regex> [!]<env-variable>=<value>Sets the environment variable if the environment variable1's value 
matches the defined regular expression.
 $1..$9within the value and are replaced by parenthesized subexpressions 
of the regular expression.This directive may be used on a per-server or
location
  basis.
QS_SetEnv <env-variable> <value>Sets the defined variable with the value where the value string may contain 
other environment variables surrounded by "${" and "}". The variable is only 
set if all defined variables within the value have been resolved.
QS_SetEnvIfQuery <regex> [!]<env-variable>[=<value>]Directive works quite similar to the
 SetEnvIf directive of the Apache module 
mod_setenvif , 
but the specified regex is applied against the query string 
portion of the request line. The directive recognizes 
the occurrences of $1..$9 within value and replaces them 
by the sub-expressions of the defined regex pattern. This directive may be used on a per-server or
location
  basis.
QS_SetEnvIfCmp <env-variable1> eq|ne|gt|lt <env-variable2> [!]<env-variable>[=<value>]Sets the defined environment variable if the specified env-variables[1|2] 
are numerical or alphabetically (case insensitive) equal (
 eq), 
not equal (ne) greater (gt), or less (lt).This directive may be used on a per-location
  basis only.
QS_SetEnvIfParp <regex> [!]<env-variable>[=<value>]Directive parsing the request payload using the Apache module 
mod_parp
  . It matches 
the request URL query and the HTTP request message body data as well 
( application/x-www-form-urlencoded,multipart/form-data, andmultipart/mixed) 
and sets the defined process variable (quite similar to theQS_SetEnvIfQuerydirective). 
The directive recognizes the occurrences of $1..$9 within 
value and replaces them by the sub-expressions 
of the defined regex pattern. This directive activates 
mod_parp for every request to the virtual host. 
You may deactivate mod_parp for selected requests using theSetEnvIf orSetEnvIfPlus directive: unset the variable "parp" to do so.
Important: request message body processing requires that the server 
loads the whole request into its memory (at least twice the length 
of the message). You should limit the allowed size of the HTTP 
request message body using theQS_LimitRequestBodydirective 
when usingQS_SetEnvIfParp!
QS_SetEnvIfBody <regex> [!]<env-variable>[=<value>]Directive parsing the request body using the Apache module 
mod_parp
  . Specify the content 
types to process using the mod_parp directive PARP_BodyData and ensure that mod_parp is enabled using theSetEnvIf orSetEnvIfPlus directive.
You should limit the allowed size of HTTP requests message body 
using theQS_LimitRequestBodydirective when using mod_parp. The directive recognizes the occurrence of $1 
within the variable value and replaces it by the sub-expressions of the 
defined regex pattern. The regular expressions is case insensitive.
QS_SetEnvIfStatus <code> <env-variable>[=<value>]Sets the defined variable in the request environment if the HTTP 
response status code matches the defined code. Default value is the status code, but 
you might override this by any other value. 
Directive may be used on a per-server or per-location basis.
 A possible use case for this directive is the prevention of 
repetitive occurrence of unwanted response status codes in 
conjunction with the
 QS_ClientEventBlockCountorQS_ClientEventLimitCountdirective.When using the special variable
 QS_Block, its 
value is set to "1" by default. There are also four "special codes" available to 
set theQS_Blockevent:
QS_SrvMinDataRatemay be used 
to setQS_Blockevents in order to limit the 
allowed number ofQS_SrvMinDataRaterule violations.
QS_SrvMaxConnPerIPmay be used 
to increment theQS_Blockevent when closing connections due to the reach of the limitation configured 
by theQS_SrvMaxConnPerIPdirective.
NullConnectiondetects connections 
which are closed even no HTTP request has been received.Note: The
 NullConnectionevent may happen silently (no log 
message) expect when usingLogLevel "debug". 
The parameter may be used to defend against SSL DoS attacks. 
Please pay attention to the fact that unused speculative TCP pre-connections of 
browsers may unintentionally cause this event as well.
BrokenConnectionmay be used 
to mark clients aborting the TCP connection before reading the whole HTTP 
response.Note: Connections may also be aborted by mod_qos if client reads 
the response too slow.
QS_SetEnvIfResBody <string> [!]<env-variable>Adds the defined environment variable (e.g.,
 QS_Block) 
if the response body contains the defined literal string. Used on a per-
location level. Only one directive may be defined per-location 
(one search string per response). Prefixing the variably by a "!" 
lets the variable being removed (unset). You may set the QS_SetEnvIfResBodyIgnoreenvironment variable if you want mod_qos to skip (not parsing) a request's response 
body.
QS_SetEnvRes <env-variable> <regex> <env-variable2>[=<value>]Sets the environment variable (env-variable2) if the regular expression (regex) matches 
against the value of the environment variable (env-variable). Occurrences of $1..$9 within 
the value are replaced by parenthesized subexpressions of the regular expression.
QS_SetReqHeader [!]<header name> <env-variable> [late]Sets the defined HTTP request header with the value of the specified 
environment variable if the variable is available.
 The header is unset (removed from the request) if the header name is prefixed by a "!".
QS_SetEnvResHeader <header name> [drop]Sets the defined HTTP response header (name and value) to the request environment variables. 
Deletes the specified header if the action 'drop' has been specified.
QS_SetEnvResHeaderMatch <header name> <regex>Sets the defined HTTP response header (name and value) to the request environment variables if 
the specified regular expression (pcre, not case sensitive) matches 
the header value.
QS_UnsetReqHeader <header name>The request header of this name is removed.
QS_UnsetResHeader <header name>The response header of this name is removed.
QS_RedirectIf <variable> <regex> [<code>:]<url>Redirects the client to the configured url if the regular expression (case insensitive)
matches the value of the the environment variable. Occurrences of $1..$9 
within the url are replaced by parenthesized subexpressions of the 
regular expression. The default status code used by this directive is 302
but you may prefix the url parameter by 307: or 301: to change 
it to a "307 Temporary Redirect" or "301 Moved Permanently" response. 
Directive may be used on a per-server or per-location basis.
 
| Sample of event rules: 
 
# marks clients coming from the internal network:
SetEnvIf    Remote_Addr      ^192\.168\.            QS_Intra
# marks clients neither coming from the internal network
# nor are VIP clients as low priority clients:
QS_SetEnvIf !QS_VipRequest   !QS_Intra              QS_LowPrio=1
# limits the request rate for low priority (neither VIP nor internal)
# clients (and no more than 400 concurrent requests for them):
QS_EventPerSecLimit          QS_LowPrio             100
QS_EventRequestLimit         QS_LowPrio             400
# detects the variable "file" within the query portion of the URL:
QS_SetEnvIfQuery             file=([a-zA-Z]*)       QS_LowPrio=$1
# combine variables and propagate them to the application via HTTP header:
SetEnvIf    Content-Length   ([0-9]*)               QS_Length=$1
QS_SetEnv   QS_Type          "length=${QS_Length}; file=${QS_LowPrio}"
QS_SetReqHeader              X-File                 QS_Type
# limit the max. body size since mod_parp loads the whole message into
# the memory servers's:
QS_LimitRequestBody          131072
# body pattern detection, example limits the maximum number of concurrent
# requests posting "id=1234" to ten:
QS_SetEnvIfParp  id=([0-9]*) PARP_PATTERN=$1
QS_EventRequestLimit         PARP_PATTERN=1234      10
# but ignore requests to the location /main/ (any sub-locations):
SetEnvIf    Request_URI      /main/.*               !parp
 |  Request Level, Generic FilterThese filters are defined on a per-
location level and are used to restrict access to resources in 
general, independent of server resource availability. 
New rules are added by defining a rule id prefixed by a '+'. Rules are merged 
to sub-locations. If a rule should not be active for a sub-location, the 
very same rule must be defined, but instead, the rule id must be prefixed with a '-'. The filter rules are implemented as Perl-compatible regular expressions 
(pcre) and are applied to the decoded URL components (un-escaped characters, 
e.g., %20 is a space). The generic request filter ignores the 
VIP status of a client. Note: Compile mod_qos with the preprocessor definition
 -DQS_MOD_EXT_HOOKSto enable the decoding hooks defined 
inmod_qos.hif you intend to implement additional
decodings by other Apache modules.
QS_DenyRequestLine '+'|'-'<id> 'log'|'deny' <pcre>Generic request line (method, path, query, and protocol) filter used to 
deny access for requests matching the defined expression (pcre, case insensitive). 
The action taken for matching rules is either 'log' (access is granted but the rule 
match is logged) or 'deny' (access is denied).
QS_DenyPath '+'|'-'<id> 'log'|'deny' <pcre>Generic abs_path (see RFC 2616 section 3.2.2) filter used to deny access 
for requests matching the defined expression (pcre, case insensitive). 
The action taken for matching rules is either 'log' (access is granted 
but the rule match is logged) or 'deny' (access is denied).
QS_DenyQuery '+'|'-'<id> 'log'|'deny' <pcre>Generic query (see RFC 2616 section 3.2.2) filter used to deny access for 
requests matching the defined expression (pcre, case insensitive). 
The action taken for matching rules is either 'log' (access is granted 
but the rule match is logged) or 'deny' (access is denied).
QS_InvalidUrlEncoding 'log'|'deny'|'off'Enforces correct URL decoding in conjunction with the
 QS_DenyRequestLine,QS_DenyPath, andQS_DenyQuerydirectives.
Default is "off" which means that an incorrect encoding does stop
request processing.
QS_Decoding 'uni'Enables additional string decoding functions which are applied before 
matching
 QS_Deny*andQS_Permit*directives. 
Default is URL decoding (%xx, \\xHH, '+').Available additional decodings:
 
uni: unicode decoding for MS IIS (%uXXXX and \uXXXX) encoded characters.
QS_DenyEvent '+'|'-'<id> 'log'|'deny' [!]<env-variable>Rule matching requests having the defined process environment variable set 
(or NOT set if prefixed by a '!'). 
The action taken for matching rules is either 'log' (access is granted 
but the rule match is logged) or 'deny' (access is denied).
QS_PermitUri '+'|'-'<id> 'log'|'deny' <pcre>Generic URL (path and query) filter implementing a request pattern 
allow list. Only requests matching at least one
 QS_PermitUripattern are allowed. If aQS_PermitUripattern has 
been defined and the request does not match any rule, the request 
is denied. 
All rules must define the same action. pcre is case sensitive.
QS_DenyInheritanceOffDisables inheritance of
 QS_Deny*andQS_Permit*directives (pattern definitions) to a location.
QS_RequestHeaderFilter 'on'|'off'|'size'Filters request headers using validation rules provided by mod_qos. 
Suspicious headers (not matching the pattern or those which are too long) are normally 
dropped (removed from the request). Abnormal
 content-*headers cause 
request blocking. Only the defined headers are allowed (allow list). Custom 
rules (additional headers or different pattern/size definitions) may be 
added using theQS_RequestHeaderFilterRuledirective.This directive has three different operation modes: 'on' (activated), 'off' (disabled), 
and 'size' (activated). The operation mode enabled by 'size' does not check the header 
values against the patterns but limits the maximum length of request header 
values only (similar to the Apache directive
 LimitRequestFieldsizebut with an individual rule for each header field). 
This directive may be used on a per-server or per-location level.Notes:
 Header validation is also useful to avoid bypassing of 
SetEnvIf /SetEnvIfPlus (if configured on a per-location level) directive settings as request headers have higher priority than 
environment variables for those 
directives and therefore a header sent a by client 
can override an environment variable having the same name.
You might also configure deny list rules (delete unwanted headers) using the 
QS_UnsetReqHeaderorQS_UnsetResHeaderdirective.
QS_RequestHeaderFilterRule <header name> 'drop'|'deny' <pcre> <size>Used to add custom request header filter rules, e.g., to override the 
internal rules (different pcre or size) 
or to add additional headers which should be allowed. 
Definitions are made globally (outside VirtualHost). The list of all loaded rules 
is shown at server startup when using
 LogLevel "debug". pcre is 
case sensitive. The size parameter defines the maximum length of a header value. 
The action 'drop' removes a header not matching the pcre, the action 'deny' 
rejects a request including such a header not matching the pcre.
QS_ResponseHeaderFilter 'on'|'silent'|'off'Filters response headers using validation rules provided by mod_qos.
Suspicious headers (not matching the pattern or those which are too long) are removed 
from the response. Only the defined headers are allowed. Filter 
is activated ('on' or 'silent') or deactivated ('off').
QS_ResponseHeaderFilterRule <header name> <pcre> <size>Used to add custom response header filter rules, e.g., to override the 
internal rules 
(different pcre or size) or to add additional headers which should be allowed. 
Definitions are made globally (outside VirtualHost). A list of all loaded rules 
is shown at server startup when using
 LogLevel "debug". pcre is 
case sensitive. The size parameter defines the maximum length of a header value. 
Body data filtering requires mod_parp  which processes the request's message body of the following HTTP request content types: application/x-www-form-urlencoded,multipart/form-data, andmultipart/mixed. The content typeapplication/jsonmay be processed by the built-in JSON parser of mod_qos. The body 
data is transformed into a request query and may be filtered using theQS_DenyQueryandQS_PermitUridirectives. 
Set the
QS_DenyQueryBody 'on|'off'Enables request  body data filtering for the
 QS_DenyQuerydirective.
QS_PermitUriBody 'on|'off'Enables request body data filtering for the
 QS_PermitUridirective.
QS_LimitRequestBody <bytes>Limits the allowed size of an HTTP request message body. This directive may 
be placed anywhere in the configuration. Alternatively, the limitation 
may be set as an environment variable using 
mod_setenvif
  (overriding the directive settings). QS_DeflateReqBodyvariable if the request body data has to 
be deflated (compressed data) using 
mod_deflate . 
You may enable request body filtering for arbitrary content types:| Sample configuration: 
 
# optional audit log writing the request body data to a file, format:
#   %h:
#   The remote host (used to filter by IP address).
#   %>s:
#   The HTTP response status code.
#   %{qos-loc}n
#   The matching Location to generate the rules for.
#   %{qos-path}n%{qos-query}n
#   The request data to define rules.
CustomLog             logs/qsaudit_log  "%h %>s %{qos-loc}n %{qos-path}n%{qos-query}n"
# enable json parser
PARP_BodyData               application/json
QS_RequestHeaderFilter      on
# limit the max. body size since mod_parp loads the whole message into the
# servers's memory:
SetEnvIfNoCase Content-Type application/x-www-form-urlencoded QS_LimitRequestBody=131072
SetEnvIfNoCase Content-Type multipart/form-data               QS_LimitRequestBody=131072
SetEnvIfNoCase Content-Type multipart/mixed                   QS_LimitRequestBody=131072
SetEnvIfNoCase Content-Type application/json                  QS_LimitRequestBody=65536
# enable mod_deflate input filter for compressed request body data:
SetEnvIfNoCase Content-Encoding (gzip|compress|deflate)       QS_DeflateReqBody
<Location /app>
   # don't allow a certain string pattern within the request query or
   # the request message body data:
   QS_DenyQueryBody              on
   QS_DenyQuery       +s01       deny "(EXEC|SELECT|INSERT|UPDATE|DELETE)"
</Location>
 |  
| Sample configuration: 
 
# sample (using the raw body parser of mod_parp) which denies XML documents
# containing the pattern "<code>delete</code>":
PARP_BodyData               text/xml
SetEnvIfNoCase Content-Type text/xml.*                        parp
SetEnvIfNoCase Content-Type application/xml                   QS_LimitRequestBody=65536
QS_SetEnvIfBody             <code>delete</code>               DENYACTION
<Location /app/web>
   QS_DenyEvent             +BADCODE deny                     DENYACTION
</Location>
 |  
 MilestonesYou may define a number of resources (request line patterns) as milestones. A 
client must access these resources in the correct order as they are defined within 
the server configuration. A client is not allowed to skip these milestones (but may access 
any other resource not covered by a milestone in between requests to milestones).
QS_MileStone 'log'|'deny' <pattern> [<thinktime>]Defines request line patterns a client must access in the defined order as
they are defined in the configuration file. The optional 'thinktime' parameter
defines the minimal elapse time (in seconds) between two milestones.
Milestones are defined on a per-server basis, outside
location
  . 
Access to milestones is tracked by a dedicated
session cookie (QSSCD).
QS_MileStoneTimeout <seconds>Defines the time in seconds within which a client must reach the next
milestone. Default are 3600 seconds.
 
| Sample configuration: 
 
# four milestones:
# 1) client must start with /app/index.html
# 2) and then read some images (e.g. media used within the first page)
# 3) before posting data to /app/register
# 4) afterwards, the user may download zip files
QS_MileStone          deny       "^GET /app/index.html"
QS_MileStone          deny       "^GET /app/images/.*"
QS_MileStone          deny       "^POST /app/register*"
QS_MileStone          deny       "^GET /app/.*\.zip HTTP/..."
 |  Connection Level Control
The module features the following directives to control server access on a per-server 
(TCP connection) level. These directives must only be used in the global server context 
and for port based virtual hosts. 
Virtual hosts neither defining QS_SrvMaxConn,QS_SrvMaxConnClose, 
norQS_SrvMaxConnPerIPare using the base server's settings and counters. 
And do not use these three directives for name based virtual hosts! 
QS_SrvMaxConn <number>Defines the maximum allowed number of concurrent
TCP connections for this server (virtual host).
QS_SrvMaxConnClose <number>[%]Defines the maximum number of connections for this server (virtual host) supporting 
HTTP keep-alive. If the number of concurrent 
connections exceeds this threshold, the TCP connections 
gets closed after each request. You may specify the number of 
connections as a percentage of
 MaxClients if adding the suffix '%' to the 
specified value. Note: It's also possible to control the Keep-Alive settings dynamically using 
the
 QS_KeepAliveTimeoutandQS_MaxKeepAliveRequestsenvironment variables.
QS_SrvMaxConnPerIP <number> [<connections>]Defines the maximum number of connections per source IP address for this server (virtual host). 
The "connections" argument defines the number of busy connections of the server 
(all virtual hosts) to enable this limitation, default is 0 (which means that the limitation 
is always enabled, even the server is idle).
QS_SrvMaxConnExcludeIP <address>Defines an IP address or address range to be excluded from connection 
level control restrictions (trusted proxy servers). An address range 
must end with a "." or ":".
QS_SrvMaxConnPerIPIgnoreVIP 'on'|'off'Tells the
 QS_SrvMaxConnPerIPdirective 
to ignore (if set to "on") the VIP status of 
clients. Default is "off", which means thatQS_SrvMaxConnPerIPgets 
disabled for VIPs.
QS_SrvMinDataRate <bytes per second> [<max bytes per second> [<connections>]]Defines the minimum upload/download throughput a client must generate (the bytes 
sent/received by the client per seconds). This bandwidth is measured while 
receiving request data (in: request line, header fields, or body), sending response data 
(out: header fields, body) and during keep-alive (enforce keep-alive).
The client connection is closed if the client does not fulfill this required minimal 
data rate and the IP address of the causing client is marked in order to be handled 
with low priority (see the
 QS_ClientPreferdirective). 
The "max bytes per second" activates dynamic minimum throughput control: 
The required minimal throughput is increased in parallel to the number of concurrent clients 
sending/receiving data (starts increasing when reaching the "connections" threshold) 
as a percentage of the "max bytes per second" which maximum is reached when the number of 
sending/receiving clients is equal to theMaxClientssetting. 
The "connections" argument is used to specify the number of busy TCP connections a 
server must have to enable this feature (used to disable theQS_SrvMinDataRaterule enforcement on idle servers).This directives must only be used in the global server context.
QS_SrvRequestRate <bytes per second> [<max bytes per second>]Same as
 QS_SrvMinDataRatebut enforcing a 
minimal upload (reading request) throughput only.
QS_SrvDataRateOffDisables the
 QS_SrvMinDataRateorQS_SrvRequestRateenforcement 
for a virtual host.
QS_SrvMinDataRateOffEvent '+'|'-'<env-variable>Disables the
 QS_SrvMinDataRateorQS_SrvRequestRateenforcement 
for a connection when the defined process environment variable is set. 
The '+' prefix is used to add a variable to the configuration while the '-' prefix 
is used to remove a variable. Directive may be used on a per-server or a 
per-location basis.
QS_SrvSampleRate <seconds>Defines the sampling rate used to measure the data throughput. 
Default is 5 seconds or the value you have used for
 QS_REQ_RATE_TMwhile compiling the module. 
Increase this value if you want to compensate bandwidth 
variations.This directives must only be used in the global server context.
 Note: It might also be increased to avoid too many error messages generated by a
 QS_SrvMinDataRaterule for clients opening unused TCP pre-connections 
which might happen if Apache'sTimeOut directive is set to higher value than this sample rate.
QS_SrvMinDataRateIgnoreVIP 'on'|'off'Tells the
 QS_SrvMinDataRatedirective 
to ignore (if set to "on") the VIP status of 
clients. Default is "off", which means thatQS_SrvMinDataRategets 
disabled for VIPs.
QS_SrvSerialize 'on'|'off' [<timeout>]Ensures that not more than one request having the
 QS_SrvSerializevariable set is processed at the same time by 
serializing them 
(process one request after each other). Default is "off".Note: Maximum wait time for a request is defined by the 
optional timeout parameter (in seconds). The default is 300 seconds.
Throttling the download bandwidth: 
mod_qos does not support bandwidth limitation on a per connection 
basis but you might use the RATE_LIMITfilter 
provided by the Apache module 
mod_ratelimit to implement a bandwidth rate limitation for connections. Client Level Control
Client level control rules are applied per client (IP source address). 
These directives must only be used in the global server context. 
 
QS_ClientEntries <number>Defines the number of individual clients managed by mod_qos. 
Default is 50'000 concurrent IP addresses. Each client requires 
about 150 bytes memory on a 64bit system (depending on how many
 QS_ClientEventLimitCountevents you have configured). Client IP source address store 
survives graceful server restart. The maximum value is 10'000'000.
QS_ClientEventRequestLimit <number>Defines the allowed number of concurrent 
requests coming from the same client source IP address having the
 QS_EventRequestvariable set.Note: You may use the
 QS_ClientIpFromHeaderdirective to override the client's IP address based on the value within the defined 
HTTP request header (e.g., X-Forwarded-For) instead of taking the IP address of 
the client which has opened the TCP connection.
QS_ClientEventPerSecLimit <number>Defines how often a client may cause a
 QS_Eventper second. Such events are requests having theQS_Eventvariable set, e.g., defined by 
using theSetEnvIf directive. 
The rule is enforced by adding a delay to requests causing 
the event (similar to theQS_LocRequestPerSecLimitdirective).
QS_ClientEventBlockCount <number> [<seconds>]Defines the maximum number of
 QS_Blockevents allowed within the defined time (default is 600 seconds). 
Client IP is blocked when reaching this counter for the specified 
time (blocked at connection level: user might not always get a 
user friendly error response).Notes:
 
You may use QS_ClientEventBlockExcludeIP <addr>to exclude an IP address from being processed by this limitation 
(e.g. for trusted clients connecting via a proxy server). An address 
range must end with a "." or ":".The counter can be decremented by setting the environment
variable QS_Block_Decrement.
QS_ClientEventLimitCount <number> [<seconds> [<variable>]]Defines the maximum number of requests 
having the defined environment variables 
(
 QS_Limitby default) set allowed within 
the defined time (default is 600 seconds). Requests from client IP's reaching 
this limitation are denied for the specified time (blocked at request level).Notes:
 
The value of the variable defines the penalty points by which the counters 
are increased. Default (empty or non-numeric value) is 1 (increment per request).You may use the QS_ClientIpFromHeaderdirective to determine the client's IP address based on the defined HTTP 
request header (e.g., X-Forwarded-For) instead of taking the IP address 
of the client which has opened the TCP connection.The current value of this counter is stored within the variable suffixed 
by _Counter, e.g.QS_Limit_Counterfor further 
processing by other rules.The remaining time (in seconds) is stored within the variabled suffixed 
by _Remaining, e.g.QS_Limit_Remainingto be 
used within SSI error pages.The counter can be reset by setting the environment variable which name is 
suffixed by _Clear, e.g.QS_Limit_Clear.The counter can be decremented by setting the environment variable which name is 
suffixed by _Decrement, e.g.QS_Limit_Decrement.Adding/removing events (configuration changes) require a server restart 
(graceful restart is not supported).Only the default rule (QS_Limit) is accessibly by the 
status viewer (you may use the 
console to view other variables alternatively).See also QS_CondClientEventLimitCountif you want to enforce a rule under certain conditions only.
QS_ClientSerializeSerializes requests having the
 QS_Serializevariable set if they are coming from the same IP address.Notes:
 
You may use the QS_ClientIpFromHeaderdirective to 
override the client's IP address based on the value within the defined HTTP request 
header (e.g., X-Forwarded-For) instead of taking the IP address of the client which has opened 
the TCP connection.Maximum wait time for a request is 5 minutes.
QS_ClientPrefer [<percent>]Accepts only VIP 
and high priority clients when the server has less than 80% 
(or the defined percentage) of free TCP connections. The server 
continues dropping more and more clients 
(also those with few penalty points) the higher the number of connections 
grows.
 Use the
 QS_VipHeaderNameorQS_VipIPHeaderNamedirective in order to identify VIP clients.The distinction between high and low priority clients is made
based on penalty points which are calculated based of these attributes:
 
HTTP requests causing a client to get marked as "low priority" have the 
"r;" event within the mod_qos_ev variable set.
You may use the status viewer to determine 
which client addresses are identified as low priority clients. Feature is 
disabled if directive is not set.Data transfer behavior (clients sending data slowly / their transfer rate) (0x01).Accessing "unusual" content types (see QS_ClientToleranceandQS_ClientContentTypes) 
(0x00 unknown / 0x02 normal / 0x04 unusual).Causing events blocking / 
limiting them (0x08 block / 0x10 limit).If their connections get closed due to timeouts (0x20). A low priority flag is cleared after 24h hours. Clients identified by
 QS_SrvMaxConnExcludeIPare excluded from connection restrictions. Filter is applied on connection level 
blocking clients even before the server starts reading the HTTP request data.
QS_ClientTolerance <percent>Defines the allowed variation from a "normal" client (average) behavior when enabling 
the
 QS_ClientPreferdirective. Default is 20%.
QS_ClientContentTypes <html> <css/js> <images> <other> <304>Defines the distribution of HTTP response content types a client normally 
receives when accessing the server. Can only be used in conjunction with the
 QS_ClientPreferdirective.QS_ClientTolerancedefines 
the allowed deviation from these values. mod_qos normally learns the average 
behavior automatically by default (you can see the learned values within 
the status viewer or by enabling theQS_Statuslog messages) but 
you may specify a static configuration using this directive in order 
to avoid influences by a high number of abnormal clients. Default is 
automatic self-learning.
QS_ClientGeoCountryDB <path>Defines the path to the geographical database file. 
The file is a Comma Separated Value (CSV) format file 
(example). 
Each line contains the following fields:
 
The
Double quoted beginning IPv4 number of the address range, e.g. "1052272128" for 62.184.102.0
Double quoted ending IPv4 number of the address range, e.g. "1052272543" for 62.184.103.159.
Double quoted ISO 3166 country code, e.g. "FR" for France.
 QS_Countryvariable contains 
the country code for the client's IP address.Note: You may use the
 QS_ClientIpFromHeaderdirective to 
override the client's IP address based on the value within the defined HTTP request 
header (e.g., X-Forwarded-For) instead of taking the IP address of the client which has opened 
the TCP connection to evaluate this variable.
QS_ClientGeoCountryPriv <list> <connections> ['excludeUnknown']Defines a comma separated list of country codes for origin client IPv4 address 
which are allowed to access the server even if the number of busy TCP 
connections reaches the defined number of connections.
 Uses the geographical database loaded by
 QS_ClientGeoCountryDB.Clients whose IP can't be mapped to a country code can be excluded 
from the limitation by configuring the 'excludeUnknown' argument.
QS_ClientIpFromHeader <header>The
 QS_ClientIpFromHeader <header>directive can be used
to determine the client's IP address based on the defined HTTP 
request header (e.g., X-Forwarded-For) instead of taking the IP address 
of the client which has opened the TCP connection. The header must only 
contain a single IP address.It can used for the following directives:
 QS_ClientEventRequestLimit,QS_ClientEventLimitCount,QS_ClientSerialize, andQS_ClientGeoCountryDB.Notes:
 
You might also use a pseudo IP address by creating a hash from the 
header's value if you prefix the header name by a '#', 
e.g. #Authorizationto use the HTTP basic auth header.The special name #SSL_CLIENT_S_DNcreates a pseudo 
IP from the SSL client certificate's subject and issuer DN.If the remote address information has been overridden by another module such as 
mod_remoteip  , 
and you want to use this, use the special name #USERAGENT_IP(available with Apache 2.4.19 and newer). 
| Sample configuration: 
 
# allows not more than 20 events/penalty points per 10 minutes:
QS_ClientEventBlockCount                          20
# don't allow a client to access /app/start.html more than
# 20 times within 10 minutes:
SetEnvIf     Request_URI /app/start.html          QS_Block=1
# don't allow more than 4 "403" status code responses
# (forbidden) for a client within 10 minutes:
QS_SetEnvIfStatus        403                      QS_Block=5
 |  Log MessagesError Log
mod_qos writes messages to Apache's error log when 
detecting a rule violation. Each error message is prefixed by an id: 
mod_qos(<number>). These error codes (number only) 
are also written to the error notes (Apache'serror-notesnote 
as well as theQS_ErrorNotesvariable) in order to be processed within error pages using 
server-side includes (SSI). 
| 
mod_qos(00x):  initialisation event
mod_qos(01x):  request level control event
mod_qos(08x):  request level control event
mod_qos(02x):  vip session event
mod_qos(03x):  connection level event
mod_qos(04x):  generic filter event
mod_qos(14x):  generic filter event
mod_qos(05x):  bandwidth limitation event
mod_qos(06x):  client control event
mod_qos(16x):  client control event
mod_qos(07x):  console errors
mod_qos(08x):  initialisation/resource errors
mod_qos(10x):  geo errors
 |  Access Log
mod_qos adds event variables to the request record which may be added 
to access log messages.
 
mod_qos_ev Status event message of mod_qos. It's a 
single letter which is used to signalize an event: "D"=denied, "S"=pass 
due to an available VIP session, 
"V"=create VIP session (cookie), "v"=marks an IP as VIP, 
"K"=connection closed (no keep-alive), "T"=dynamic keep-alive, 
"r"=IP is marked as a slow/bad client, "L"=means a request slowdown, 
"u"=request without a user tracking cookie, 
and "s" is used for serialized requests. The letter "A" for connection abort 
is set if the status code detection
 BrokenConnectionhas been configured.
mod_qos_cr The number of concurrent requests to a 
location matching the
 QS_LocRequestLimit,QS_LocRequestLimitMatch,QS_LocRequestPerSecLimit,QS_LocRequestPerSecLimitMatch,QS_LocKBytesPerSecLimit,QS_LocKBytesPerSecLimitMatch,QS_CondLocRequestLimitMatch, 
orQS_EventRequestLimitdirective.
mod_qos_con This event shows the number of 
concurrent connections to this server. Only available if the directive
 QS_SrvMaxConnis used.
mod_qos_user_id The user id which is available when 
enabling user tracking.
 User tracking is based on a unique identifier generated by 
mod_unique_id
  . 
This unique identifier is stored as a cookie. The user tracking 
feature is enabled by setting the QS_UserTrackingCookieName <name> [<path>] [<domain>] ['session'] ['jsredirect']directive.Options of the
 QS_UserTrackingCookieNamedirective are:
Notes:The nameargument defining the name of the 
user tracking cookie.The pathspecifies a local error document 
which is shown if a user does not accept the cookie (enforcement).You may disable this enforcement for certain clients by setting the
 DISABLE_UTC_ENFORCEMENTenvironment variable at server 
level (outside Location), e.g., to allow crawlers not supporting 
cookies to access your site.This option can be used to ensure whether a client/browser accepts cookies 
at all which might be a requirement of your application.
domaindefines optionally the domain attribute for 
the Set-Cookie header.The sessionflag indicates that a short lived (per 
session) cookie shall be created which won't be stored by the browser 
permanently.When using the additional option 'jsredirect', 
the client (browser) has to interpret Javascript used within the 
cookie check page 
to fetch the cookie and to execute the redirect back to the initially 
requested page (adding Javascript to the cookie challenge).The following SSI variables can be used:
 
QS_UT_QUERY: Query string to call (ajax) the cookie 
page again to obtain the cookie.QS_UT_NAME: Name of the cookie.QS_UT_INITIAL_URI: Initial page to redirect to. 
QS_UserTrackingCookieNameignores theQS_LogOnlydirective.The cookie is secured by the QS_SessionKeyand you should set this directive to have a constant key.
UNIQUE_ID This is a unique request id generated by 
mod_unique_id. mod_qos uses this id to mark messages written to the 
error log. So it might be useful to log the
 UNIQUE_IDenvironment variable as well, in order to correlate errors 
to access log messages.
QS_ConnectionId Connection correlation id used to 
mark all messages belonging to the same TCP connection.
 
| Sample configuration: 
 
LogFormat "%h %u %t \"%r\" %>s %b %T \"%{content-length}i\" %k \"%{User-Agent}i\" \
           %{mod_qos_cr}e %{mod_qos_ev}e %{mod_qos_con}e %{QS_SrvConn}e %{QS_AllConn}e \
           id=%{UNIQUE_ID}e %{QS_ConnectionId}e %{mod_qos_user_id}e %{QS_Country}e #%P"
 |  Request Statistics
The qslogtool, which is part of 
the support utilities of mod_qos, may be used to gather request 
statistics from Apache's access log data. This includes data such 
as the number of denied requests or new VIP session creations per 
minute but also total requests per second and other data. Refer 
to the usage text of theqslogutility and read "Request Statistics Using qslog" 
for further details. 
| 
CustomLog "|/usr/bin/qslog -o logs/qslog.csv -x -f ISBDQkU" \
          "%h %>s %b %D %{mod_qos_ev}e %k %{mod_qos_user_id}e"
 |  
Instead of using the standard Apache log CustomLogdirective, 
you may use theQSLogdirective of mod_qos alternatively. This
allows you to configure a single log file for your Apache instance (globally, 
not per virtual host) and you don't have to specify the format (-f) option. 
| 
QSLog "|/usr/bin/qslog -o /var/log/apache/qslog.csv"
 |  Status Viewer
mod_qos features a handler showing the current connection and request status. 
 
A machine-readable version of the status information is available when using 
the request query string| 
<Location /qos>
   SetHandler qos-viewer
</Location>
 |  auto, e.g.,http://your.server.name/qos?auto. The page updates itself 
automatically every 10 seconds if you add the request 
query stringrefresh, e.g.,http://your.server.name/qos?refresh.Note: This view also shows you the error log event 
counters if you enable event (errors and warnings) counting by 
configuring
 QS_EventCount onand are using any 
client level limitation usingQS_Client*directives.
The status information is also provided on the server status page of 
mod_status  (although in a reduced scope). Note: Compile mod_qos with the preprocessor definition
 -DQS_NO_STATUS_HOOKto disable its registration to 
the status page rendered by mod_status. 
Use the directive QS_DisableHandler onto disable the qos-viewer and qos-console for 
a virtual host in order to prevent accidental activation of these functions, including by configuration 
settings of per-directory files (e.g., .htaccess). 
The directive QS_Status 'on'|'off'may be used to enable a 
status log message (mod_qos(200)) written to the Apache server'sErrorLog. This message contains information about the server's 
scoreboard. The message is written once every minute. Web Console
mod_qos implements an Apache handler which acts as a web console for setting attributes via HTTP requests.
 
Access a location where you have enabled the| 
<Location /qos/console>
   SetHandler qos-console
</Location>
 |  qos-consolehandler 
with a web client and use the following request query parameter to modify 
the status of a client (may only be used if client level control 
has been enabled).
address=<IP address>Specifies the IP address of the client to modify.
action='block'|'unblock'|'limit'|'unlimit'|'inclimit'|'setvip'|'unsetvip'|'setlowprio'|'unsetlowprio'|'search'Defines the command to be executed, or the attribute to be changed.
 
block: blocks the client for the configured period of time, 
see alsoQS_ClientEventBlockCount.unblock: clears the block attribute of the client.limit: denies requests 
from the client IP for the configured period of time, see alsoQS_ClientEventLimitCount.unlimit: clears the limit 
attribute of the client.inclimit: increments the client's limit counter.setvip: sets the client status to VIP.unsetvip: clears the VIP status for a client.setlowprio: sets the client's priority to 'low'.unsetlowprio: clears the 'low' priority
attribute of the client.search: verifies the availability of a client IP address.Use the asterisk (*) 
for the
 addressparameter in order to get a list of all available clients (dump).event=<name>Specifies the event name of the
 QS_ClientEventLimitCountdirective counter which shall be
shown or modified (used in conjunction with thelimit,unlimit,inclimit, andsearchaction).
Default isQS_Limit. 
The output (which is plain text) contains the following fields:
The wildcard search ( address=*) generates a by a newline separated list of
all client IP entries. Each line is prefixed by an index and terminated
by the time of the last entry update (seconds since epoch).
The console may be used to manually update the status of a client (IP) or 
for automated actions. Examples:
 
To unlock a client which got blocked by mistake.To synchronize events within multiple Apache instances. An example using
 qsexecis available within the 
source code repository.Download/upload client status from one 
Apache instance to another (or to the same instance, 
e.g., when restarting an instance). 
Examples to access the console:
 
Sets VIP status for the IP 194.31.217.21:
 http://your.server.name/qos/console?action=setvip&address=194.31.217.21Clears the QS_Limit counter for the IP 194.31.217.21:
 http://your.server.name/qos/console?action=unlimit&address=194.31.217.21&event=QS_Limit 
The status viewer may be used as well to 
verify the status of the client. Example: 
 http://your.server.name/qos?action=search&address=194.31.217.21 Utilities
mod_qos provides optional tools for log data processing and analysis:
 
qsgeoAdds the country code 
for the client IP address within a log file.
qslogA real time
 TransferLog/CustomLog data analyzer. It reads the per request log data from stdin and generates 
statistic records every minute.qsreRegular expression (pcre) 
pattern match test tool.
qsrespeedCompares the 
expected processing time per regular expression.
 Sample Use CasesThe following use cases may give you an idea about how to use mod_qos.Slow Application
In case of a very slow application (e.g., at location /ccc), requests wait 
until a timeout occurs. Due to many waiting requests, there are no free TCP 
connections left and the web sever is not able to process other requests 
to applications still working fine, e.g., to /aaa, /bbb /dd1, and /dd2. 
mod_qos limits the number of concurrent 
requests to an application in order to 
assure the availability of other resources.
The
 Example:
 
 qslogtool may be used 
to analyze your log files in order to identify "slow" resources by 
using the-pu,-puc, or-coption.HTTP Keep-Alive
The keep-alive extension of HTTP 1.1 allows persistent TCP connections for 
multiple requests/responses. This accelerates access to the web server due to less and optimized network traffic. The disadvantage of these persistent 
connections is that server resources are blocked even when no data is exchanged 
between client and server. mod_qos allows a server to support keep-alive 
as long as sufficient connections are available, but stops the keep-alive 
support when it reaches a defined connection threshold. 
 Example:
 
 
| 
# maximum number of active TCP connections is limited to 256 (limited
# by the available memory, adjust the settings according to the
# used hardware):
MaxClients              256
# disables keep-alive when 70% of the TCP connections are occupied:
QS_SrvMaxConnClose      70%
 |  Client Opens Many Concurrent Connections
A single client may open many TCP connections simultaneously in order to 
download different content from the web server. So the client gets many 
connections while other users may not be able to access the server because
no free connections remain for them. mod_qos can limit the number 
of concurrent connections for a single IP source address. 
 Example:
 
 
| 
# maximum number of active TCP connections is limited to 896
# (limited by the available memory, adjust the settings according to the
# used hardware):
MaxClients              896
# don't allow a single client to open more than 50 TCP connections if
# the server has not more than 196 free connections:
QS_SrvMaxConnPerIP      50 700
 |  Many Requests to a Single URL
If you have to limit the number of requests to an URL, mod_qos can help 
with that, too. You may limit the number of requests per second to 
an URL. mod_qos will then calculate the necessary delay time to be added 
to each requests accessing this resource in order to achieve the defined 
limitation. 
 Example:
 
 
Alternatively, if you need to reduce the number of processed requests 
per time to a very low value, you might add a (predefined or 
dynamically calculated) delay to each request and process only 
one of them at the same time. However, this will delay every 
request to the defined URI, even the server is idle.
 Example:
 
 
| 
# does not allow more than 4 requests/sec by adding a wait time of 250ms
# to each request and process only one request at once:
SetEnvIf                 Request_URI ^/download/mod_qos.so.gz QS_SrvSerialize=1
SetEnvIf                 Request_URI ^/download/mod_qos.so.gz QS_Delay=250
QS_SrvSerialize          on
# but do not allow more than 600 concurrent requests:
QS_EventRequestLimit     QS_SrvSerialize 600
 |  
mod_qos can also restrict the access to an URL by limiting the number 
of requests from a single IP address (LimitDownloadCounteris 
the counter to use while theLimitDownloadNowpattern is used to limit access to this 
specific resource only still allowing the IP address to access 
other resources).
 Example:
 
 
| 
# does not allow more than 4 downloads of mod_qos.so.gz per minute from a single IP address:
SetEnvIf                     Request_URI ^/download/mod_qos.so.gz LimitDownloadCounter
SetEnvIf                     Request_URI ^/download/mod_qos.so.gz QS_Cond=LimitDownloadNow
QS_CondClientEventLimitCount 4 60 LimitDownloadCounter LimitDownloadNow
 |  Bandwidth Restriction
It's sometimes necessary to restrict the bandwidth consumed by 
clients downloading certain type of data in order to avoid 
that the entire bandwidth of your Internet connection is 
exploited by less important data traffic, e.g. if your web server 
hosts large files to be downloaded.mod_qos allows you to defined the bandwidth which may be 
used when accessing a defined URL or when the server returns a 
certain content-type.
 
 Example:
 
 Brute Force
Sometimes, you want to limit how often a resource may be accessed 
within a certain amount of time, e.g., to defend against brute-force 
respectively dictionary attacks or an account lockout DoS (someone 
systematically locks user accounts by too many invalid sign-in 
attempts). mod_qos allows you to limit this either server wide 
(any request accessing the resource) by using the 
QS_EventLimitCountdirective, 
or on a per client IP basis using theQS_ClientEventLimitCountdirective.
 Example:
 
 
Note: Multiple users may share an IP addresses which might cause false 
positives. You might avoid this by decrementing the counter on successful 
user authentication / login, e.g. by setting the variable| 
# allows a single IP address to access the URI /wp-login.php not more
# than 10 times within an hour:
SetEnvIf                 Request_URI ^/wp-login.php LimitLogin
QS_ClientEventLimitCount 10 3600 LimitLogin
 |  LimitLogin_Decrement=1.
A brute force attack might also be performed by many distributed 
clients (thousands of clients, but every client performs a few 
requests only). To add protection to your server, you might configure an 
overall limitation for critical resources allowing only known clients 
(VIPs) 
to access your server without any restrictions. The 
QS_CondEventLimitCountdirective might be used to achieve this. Too Many Client Connections
mod_qos may prefer "known" client IP 
addresses in the case that too many clients access the server.
"Known" clients are those which have once been identified by the 
application by setting the corresponding 
HTTP response header. 
Such identification may happen at successful user login. 
Connections from clients which are not known to mod_qos 
(never marked by the corresponding response header) are denied 
if the server runs on low TCP connection resources (20% or 
fewer free connections in this example). mod_qos may 
also prefer those clients which communicate with the server 
instantaneously and fast, and denies access to slow clients 
sending data irregularly, in case the server has not enough 
resources. 
You may also set limitations defining how many resources 
may be requested by a single IP address source, e.g., using 
the QS_SrvMaxConnPerIPdirective and you can disable HTTP keep-alive 
dynamically. 
For more information about how mod_qos can help you in such situations, see the article 
"Denial of Service Defense".
 Example:
 
 
| 
# maximum number of active TCP connections is limited to 896 (limited
# by the available memory, adjust the settings according to the used
# hardware):
MaxClients              896
# idle timeout:
Timeout                   5
# keep alive (for up to 85% of all connections):
KeepAlive                on
MaxKeepAliveRequests     40
KeepAliveTimeout          2
QS_SrvMaxConnClose       85%
# name of the HTTP response header which marks preferred clients (this
# may be used to let the application decide which clients are "good" and
# have higher privileges, e.g. authenticated users.
# you may also use the QS_VipIPUser directive when using an Apache 
# authentication module such as mod_auth_basic or mod_auth_oid  ):
QS_VipIPHeaderName       mod-qos-login
# enables the known client prefer mode (server allows new TCP connections
# from known/good clients only if there are more than 716 open TCP connections):
QS_ClientPrefer          80%
# don't allow more than 30 TCP connections per client source address being
# processed if the server has 500 or more open connections:
QS_SrvMaxConnPerIP       30 500 |  |