|  | 
In computer networking, the term quality of service (QoS) describes 
resource management rather than the quality of a service. 
Quality of service implements control mechanisms to provide 
different priority to different users, applications, and data 
connections. It is used to guarantee a certain level of performance 
to data resources. The term quality of service is often used 
in the field of wide area network protocols (e.g. ATM) and 
telephony (e.g. VoIP), but rarely in conjunction with web applications. 
mod_qos is a quality of service module for the Apache web server 
implementing control mechanisms that can provide different levels of 
priority to different HTTP requests.
 
But why do you need quality of service for a web application? Well, 
web servers require threads and processes to serve HTTP requests. 
Each TCP connection to the web server occupies one of these threads 
respectively processes. Sometimes a server gets too busy to serve 
every request due to the lack of free processes or threads. Another 
parameter requiring control by mod_qos is the available bandwidth: 
all clients communicate to the server over a network link with 
limited bandwidth. Overfilling the link results in network 
congestion and poor performance.
 
Example situations where web applications require QoS:
 
More resources are consumed if request processing by an application 
takes a long time, e.g. when request processing includes 
time consuming database queries.
Oversubscription of link capabilities due to many concurrent 
clients uploading or downloading data.
Penetration of the web server by attackers (DDoS).
 
mod_qos may be used to determine which requests should be served and 
which shouldn't in order to avoid resource oversubscription. The 
module collects different attributes such as the request URL, 
HTTP request and response headers, the IP source address, the 
HTTP response code, history data (based on user session and source 
IP address), the number of concurrent requests to the 
server (total or requests having similar attributes), the number 
of concurrent TCP connections (total or from a single source IP), 
and so forth.
 
Counteractive measures to enforce the defined rules are: request 
blocking, dynamic timeout adjustment, request delay, response 
throttling, and dropping of TCP connections.
 
The current release of the mod_qos module 
implements control mechanisms to manage:
 
The maximum number of concurrent requests to a location/resource (URL) 
or virtual host.
Limitation of the bandwidth such as the maximum allowed number of requests 
per second to an URL or the maximum/minimum of downloaded kbytes per second.
Limits the number of request events per second (special request conditions).
Limits the number of request events within a defined period of time.
It can also detect very important persons (VIP) which may access the 
web server without or with fewer restrictions.
Generic request line and header filter to deny unauthorized operations.
Request body data limitation and filtering (requires 
mod_parp).
Limits the number of request events for individual clients (IP).
Limitations on the TCP connection level, e.g., the maximum number of 
allowed connections from a single IP source address or dynamic 
keep-alive control.
Prefers known IP addresses when server runs out of free TCP connections.
 
mod_qos is an open source software licensed under the 
GNU General Public License. 
Downloads are handled by 
SourceForge.net.
 
   
 
More information about mod_qos:
 
 Build
mod_qos requires OpenSSL, PCRE (don't use the version which comes with the 
Apache distribution), threading and shared memory support. mod_qos supports 
Apache version 2.2 MPM worker binaries and 
is optimized to be used in a reverse proxy server.
 Just copy the module into the
 modulesdirectory of the Apache 
server's source code and compile it using the following commands (all 
examples are using Apache 2.2.24 and mod_qos 10.28): 
This creates a DSO module that can be loaded into the Apache server using the 
following directive:| 
tar xfz httpd-2.2.24.tar.gz
tar xfz mod_qos-10.28-src.tar.gz
ln -s httpd-2.2.24 httpd
cd httpd
mkdir modules/qos
cp ../mod_qos-10.28/apache2/* modules/qos
./buildconf
./configure --with-mpm=worker --enable-so --enable-qos=shared --enable-ssl --enable-unique-id
make
cd ..
 |  
| 
LoadModule qos_module <path to module>/mod_qos.so
 |  
You can also compile the module using 
apxsalternatively. 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-10.28/apache2
apxs -i -c mod_qos.c -lcrypto -lpcre
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.
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, PCRE, 
libpng, and OpenSSL.
 
Note: 
If you have a different version of| 
cd mod_qos-10.28/tools
./configure
make
 |  aclocalorautomakeon your system (you get a message like 
"aclocal-1.11 is missing on your system"), try to executeaclocalmanually and executemakeagain.Source
mod_qos is available for Apache version 2.2.
 ConfigurationConfiguration is done on a per-server basis (except the generic request 
filter). Commands within a virtual host are merged with the settings in 
the global configuration.
 
The QS_SrvMinDataRate,QS_SrvRequestRate,QS_RequestHeaderFilterRuleand 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 no 
actions are applied to requests or connections to enforce a rule. 
This may be used for test purposes. Request Level ControlThe module features the following directives to control server access 
on a per-URL level. Only oneQS_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 
(applied to the unparsed URL). 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).
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 (non-linear, bigger files get longer 
delay than smaller ones because bandwidth calculation is based on an 
average response body size 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_LocKBytesPerSecLimitMatchandQS_LocRequestLimitMatchdirective).
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). Has lower priority thanQS_LocRequestPerSecLimitMatch.
QS_LocKBytesPerSecLimit <location> <number>Throttles the download bandwidth to the defined kbytes per second. Works 
simlar 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). Has lower priority thanQS_LocKBytesPerSecLimitMatch.
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 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 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*orSetEnvIfdirective. 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. Used when using the same 
session cookie for multiple web servers (load balancing) or 
sessions should survive a server restart. By default, 
a random key is used which changes every server restart.
 
| Sample configuration: 
 
QS_ErrorPage                  /error-docs/qs_error.html
# restricts max concurrent requests for any location which has no
# individual rule:
QS_LocRequestLimitDefault                              200
# limits access to *.gif files to 100 concurrent requests:
QS_LocRequestLimitMatch       "^.*\.gif$"              100
# limits concurrent requests to the locations /images and /app/a:
QS_LocRequestLimit            /images                  100
QS_LocRequestLimit            /app/a                   300
# limits download bandwidth to 5Mbit/sec:
QS_LocKBytesPerSecLimit       /app/a                   640
# two locations (/app/b and /app/c) representing a single application:
QS_LocRequestLimitMatch       "^(/app/b/|/app/c/).*$"  300
# allows the application to nominate VIP users by sending a
# "mod-qos-vip" HTTP response header:
QS_VipHeaderName              mod-qos-vip
QS_SessionKey                 na&5san-sB.F4_0a=%D200ahLK1
 |  The following table shows if a rules may be deactivated for VIPs:
 
Note: Event based rules (e.g., QS_ClientEventLimitCount) may evaluate the 
QS_VipRequest and 
QS_IsVipRequest variables to decide 
if the rule should be applied.| 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_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* | yes |  | QS_LocRequestLimit* | yes |  | QS_LocRequestPerSecLimit* | 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 |  |  |  |  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 theQS_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_VipRequest=yesDisables the per location restrictions for this request. 
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
 KeepAliveTimeoutdirective settings.
QS_ErrorPage=<URL>Defines the error page overriding the setting made by the
 QS_ErrorPagedirective.
QS_Delay=<milliseconds>Defines a number of milliseconds to delay the request processing.
QS_EventThe variable processed by the
 QS_ClientEventPerSecLimitdirective.
QS_BlockVariable processed by the
 QS_ClientEventBlockCountdirective.
QS_Limit(Default) variable processed by the
 QS_ClientEventLimitCountdirective.
*_ClearThe counter of the variable processed by the
 QS_ClientEventLimitCountdirective  
are reset if you set the same variable suffixed by_Clear, 
e.g.QS_Limit_Clear.
QS_SerializeVariable processed by the
 QS_ClientSerializedirective.
QS_CondVariable processed by the
 QS_CondLocRequestLimitMatchdirective.
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 requests by clients which have been marked to be 
processed with low priority, see
 QS_ClientPrefer.
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 occured during a request.
QS_CountryISO 3166 country code of client IPv4 address. Only available if the geographical database file has been loaded.
 Note: You may use the
 QS_ClientIpFromHeader <header>directive 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. 
| 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        (.*)                     QS_ErrorPage=/error-docs/$1.html
# external redirect to a sever hosting the error page:
SetEnvIf     Request_URI /app                     QS_ErrorPage=http://server/error.html
 |  Conditional RulesConditional rules are only enforced if theQS_Condvariable matches the specified pattern.
| 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 adhere to the order of command 
execution to ensure that the necessary variables are set.
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.
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 (non-linear, bigger files get 
longer delay than smaller ones). 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_EventRequestLimitonly (you must use the same variable name for both directives).
QS_EventLimitCount <env-variable> <number> <seconds>Defines the maximum number of events allowed within the defined time. Requests are 
denied when reaching this limitation for the specified time (blocked at request level).
 Note: The current counter value is propagated to the process environment within the variable
 <env-variable>_Counter.
QS_SetEnvIf [!]<env-variable1> [!]<env-variable2> [!]<variable=value>Sets (or unsets) the "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.
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
 SetEnvIfdirective 
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.
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 theSetEnvIfdirective: 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_BodyDataand ensure that mod_parp is enabled using theSetEnvIfdirective 
of the Apache module mod_setenvif. 
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.
QS_SetEnvIfStatus <code> <env-variable>[=<value>]Sets the defined variable in the request environment if the HTTP 
response status code matches the defined code. This may be used 
in conjunction with the
 QS_ClientEventBlockCountdirective. Directive may be used on a per server or per location basis.The special code
 QS_SrvMinDataRatemay be used to setQS_Blockevents in order to limit the allowed number ofQS_SrvMinDataRaterule violations and 
the special codeNullConnectiondetects connections which are 
closed even no HTTP request has been received.
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).
QS_SetEnvResHeader <header name> [drop]Sets the defined HTTP response header 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 to the request environment variables if 
the specified regular expression (pcre not case sensitive) matches 
the header value.
QS_SetEnvRes <env-variable> <regex> <env-variable2>[=<value>]Sets the environmet 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>Sets the defined HTTP request header to the request if the specified 
environment variable is set.
QS_UnsetResHeader <header name>Removes the specified response header.
QS_RedirectIf <variable> <regex> <url>Redirects the client to the configured url if the regular expression 
matches the value of the the environment variable. Occurrences of $1..$9 
within the url are replaced by parenthesized subexpressions of the 
regular expression. 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.
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). 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). 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). 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 incorrect encodings are ignored.
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 
whitelist. 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. 
You may use theqsfilter2utility to generate rules based on access log files.
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. Custom rules 
(additional headers or different pattern/size definitions) may be 
added using the
 QS_RequestHeaderFilterRuledirective. Filter 
is activated ('on') or deactivated ('off'). The mode 'size' does not verify 
the pattern but limits the maximum length of request header values 
(similar to the Apache directiveLimitRequestFieldsizebut 
with an individual rule for each header field). Header validation is also useful 
to avoid bypassing ofSetEnvIfdirective settings.
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). A list of all 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'|'off'|'silent'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 deactivated ('off' or 'silent').
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 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:| Sample configuration: 
 
QS_ErrorPage                     /error-docs/qs_error.html
# add a custom request header rule:
QS_RequestHeaderFilterRule       UA-CPU drop "^[a-zA-Z0-9]+$" 20
# enable header validation:
QS_RequestHeaderFilter           on
<Location />
   # don't allow access to the path /app/admin.jsp:
   QS_DenyPath        +admin     deny "^/app/admin.jsp$"
   # allow printable characters only within the request line:
   QS_DenyRequestLine +printable deny ".*[\x00-\x19].*"
</Location>
 |  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: 
 
# configure the audit log writing the request body data to a file
# (use this log to generate whitelist rules using qsfilter2
# when QS_PermitUriBody has been enabled)
# format:
#   %h:
#   The remote host (used to filter by IP adress).
#   %>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 required by qsfilter2 to generate 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>
 |  
Register the mod_parp raw parser 
using the PARP_BodyDatadirective.Enable mod_parp for the content type using the SetEnvIfNoCasedirective.Use QS_SetEnvIfBodyto detect patterns within the HTTP request body.The QS_DenyEventdirective denies access for the request. 
| 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>
 |  
Milestones: you 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>Defines request line patterns a client must access in the defined order as they are defined in the 
configuration file. Milestones are defined on a per server basis, outside 
Location. 
Access to milestones is tracked by a dedicated session cookie.
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
# 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 ControlThe 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 (don't use them for name based virtual hosts).
QS_SrvMaxConn <number>Defines the maximum 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 connection 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.
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. An address range must end with a ".".
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 (request line, header fields, or body), sending response data 
(header fields, body) and during 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). 
The "max bytes per second" setting 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 (0 by default). It is used to disable theQS_SrvMinDataRaterule enforcement on idle servers.
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_SrvMinDataRateandQS_SrvMinDataRateenforcement 
for a virtual host.
QS_SrvMinDataRateOffEvent '+'|'-'<env-variable>Disables the
 QS_SrvMinDataRateandQS_SrvMinDataRateenforcement 
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-Location basis. 
| Sample configuration: 
 
# minimum request rate (bytes/sec at request reading):
QS_SrvRequestRate                                 120
# limits the connections for this virtual host:
QS_SrvMaxConn                                     800
# allows keep-alive support till the server reaches 600 connections:
QS_SrvMaxConnClose                                600
# allows max 50 connections from a single ip address:
QS_SrvMaxConnPerIP                                 50
# disables connection restrictions for certain clients:
QS_SrvMaxConnExcludeIP                    172.18.3.32
QS_SrvMaxConnExcludeIP                    192.168.10.
 |  Client Level ControlClient 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.
QS_ClientEventRequestLimit <number>Defines the allowed number of concurrent requests coming from the same 
client source IP address having the
 QS_EventRequestvariable set.
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 
mod_setenvif 
or using theQS_SetEnvIfdirective. 
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).
QS_ClientEventLimitCount <number> [<seconds> [<variable>]]Defines the maximum number of the defined environment variables 
(
 QS_Limitby default) 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:
 
You may use the QS_ClientIpFromHeader <header>directive 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.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 counter can be reset by setting the environment variable which name is 
suffixed by _Clear, e.g.QS_Limit_Clear.Adding/removing events require a server restart (graceful restart is 
not supported).Only the default rule (QS_Limit) is accessibly by the 
status viewer and the 
console.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 comming 
from the same IP address.Notes:
 
You may use the QS_ClientIpFromHeader <header>directive 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. Use the
 QS_VipHeaderNameorQS_VipIPHeaderNamedirective in order to identify VIP clients. The distinction between 
high and low priority clients is made based on the client data transfer 
behavior (clients sending slow, using small data packets, or accessing 
"unusual" content types (seeQS_ClientTolerance), 
get marked as low priority clients, look for "r;" events within the 
access log or use the 
status viewer to determine which client addresses 
are identified as low priority clients). A low priority flag 
is cleared after 24h hours. Clients identified byQS_SrvMaxConnExcludeIPare excluded from connection 
restrictions. Filter is applied on connection level.
QS_ClientTolerance <percent>Defines the allowed variation from a "normal" client (average) behavior. 
Default is 20%.
QS_ClientContentTypes <html> <css/js> <images> <other> <304>Defines the distribution of HTTP response content types a client normaly 
receives when accessing the server.
 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) but you may specify a 
static configuration using this directive in order to avoid influences 
by a high number of abnormal clients.
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:
 
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_ClientGeoCountryPriv <list> <connections>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.
 
| Sample configuration: 
 
# 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=yes
QS_ClientEventBlockCount                          20
# don't allow more than 20 "403" status code responses
# (forbidden) for a client within 10 minutes:
QS_SetEnvIfStatus        403                      QS_Block
 |  Log MessagesError Log
mod_qos writes messages to Apache's error log when enforcing a rule. Each 
error messages is prefixed by an id: mod_qos(<number>). These 
error codes (number only) are also written to the error notes 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(05x):  bandwidth limitation event
mod_qos(06x):  client control event
mod_qos(07x):  console 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_evStatus 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, "K"=connection closed 
(no keep-alive), "T"=dynamic keep-alive, "r"=IP is marked as a 
slow/bad client, "L"=means a request slowdown, and "s" is used for 
serialized requests.
mod_qos_crThe 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_conThis event shows the number of 
concurrent connections to this server. Only available if the directive
 QS_SrvMaxConnis used.
mod_qos_user_idThe user id which is available when 
enabling the user tracking. User tracking is based on a unique 
identifier generated by mod_unique_id which is stored as a 
cookie. The user tracking feature is enabled by setting the
 QS_UserTrackingCookieName <cookie name> [<path>]directive. Thecookie nameargument defines the name of the 
user tracking cookie. The optionalpathis 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 theDISABLE_UTC_ENFORCEMENTenvironment variable at server 
level (outside Location), e.g., to support crawlers or the do-not-track HTTP request 
header.
 QS_UserTrackingCookieNameignores theQS_LogOnlydirective.
UNIQUE_IDThis 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_ConnectionIdConnecton 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 for further details. 
| 
CustomLog "|/usr/bin/qslog -o logs/qs_log -x -f ISBTQkU" "%h %>s %b %T %{mod_qos_ev}e %k %{mod_qos_user_id}e"
 |  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.
The status information is also provided on the server status page of  
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, includng by configuration 
settings of per-directory files (e.g., .htaccess). 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).
Example:
address=<IP address>Specifies the IP address of the client to modify.
action='block'|'unblock'|'limit'|'unlimit'|'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: blocks (friendly) the client for the configured period of time, see alsoQS_ClientEventLimitCount.unlimit: clears the limit attribute of the client.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. Set '*' for the address 
parameter in order to get a list of all available clients. http://your.server.name/qos/console?action=setvip&address=194.31.217.21
You may use the status viewer 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:
 
qsexecCommand execution triggered by patterns within log files.
qsfilter2Rule generator. Creates
 QS_Permit*directives and rule patterns from audit log files.qsgeoAdds the country code for the client IP address within a log file.
qsgrepSearches a file for a pattern and prints the data in a new format.
qslogA real time
 TransferLog/CustomLogdata analyzer. It reads the per request log data from stdin and generates statistic 
records every minute.qsloggerShell command interface to the syslog(3) system log module.
qspngCreates graphics (png images) from the output of
 qslog.qsrotateLog rotation tool similar to Apache's
 rotatelogs.qssignA log data integrity check tool. It reads log data 
from stdin (pipe) and writes the signed data to stdout.
qstailShows the end of a log file beginning at a defined pattern.
 Use Cases
The 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.
 Example:
 
 
The| 
# 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
# limits the maximum of concurrent requests per application to 100:
QS_LocRequestLimit      /aaa                100
QS_LocRequestLimit      /bbb                100
QS_LocRequestLimit      /ccc                100
QS_LocRequestLimitMatch "^(/dd1/|/dd2/).*$" 100
 |  qslogtool may be used 
to analyze your log files in order to idenitify "slow" resources by 
using the-puor-pucoption.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 singe 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 by adding a delay to requests accessing this resource. 
 Example:
 
 
| 
# does not allow more than 150 requests/sec:
QS_LocRequestPerSecLimit /download/mod_qos.so.gz 150
# but do not allow more than 600 concurrent requests:
QS_LocRequestLimit       /download/mod_qos.so.gz 600
 |  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 
has 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 prefers also 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. A minimal request bandwidth should be enforced, in order 
to close the connections coming from idle clients. The QS_SrvMinDataRatedoes this. You may want to combine this with theQS_SrvMaxConnPerIPdirective as shown above in the "Client Opens Many Concurrent Connections" example. 
This could even be extened by the Apache module mod_reqtimeout 
which may be used to set various timeouts for receiving the request headers 
and the request body from the client. TheQS_ClientEventBlockCountdirective is used in this example to block clients for a certain amount 
of time if they cause errrors because they send invalid HTTP requests.
 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                  20
# keep alive (for up to 85% of all connections):
KeepAlive                on
MaxKeepAliveRequests     60
KeepAliveTimeout         3
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_VipUser 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 when is has more than 716 open TCP connections):
QS_ClientPrefer          80
# minimum request/response speed (deny slow clients blocking the server, 
# e.g. defending slowloris) if the server has 500 or more open connections:
QS_SrvMinDataRate        120 1500 500
# and limit request line, header and body:
LimitRequestLine         7168
LimitRequestFields       30
QS_LimitRequestBody      102400
# don't allow more than 30 TCP connections per client source address if
# 500 connections are open to the server:
QS_SrvMaxConnPerIP       30 500
# block clients violating some basic rules frequently (don't allows more than 20
# violations within 5 minutes):
QS_ClientEventBlockCount 20 300
QS_SetEnvIfStatus        400               QS_Block
QS_SetEnvIfStatus        401               QS_Block
QS_SetEnvIfStatus        403               QS_Block
QS_SetEnvIfStatus        404               QS_Block
QS_SetEnvIfStatus        405               QS_Block
QS_SetEnvIfStatus        406               QS_Block
QS_SetEnvIfStatus        408               QS_Block
QS_SetEnvIfStatus        411               QS_Block
QS_SetEnvIfStatus        413               QS_Block
QS_SetEnvIfStatus        414               QS_Block
QS_SetEnvIfStatus        417               QS_Block
QS_SetEnvIfStatus        500               QS_Block
QS_SetEnvIfStatus        503               QS_Block
QS_SetEnvIfStatus        505               QS_Block
QS_SetEnvIfStatus        QS_SrvMinDataRate QS_Block
QS_SetEnvIfStatus        NullConnection    QS_Block
 |  |