Functional and Object Oriented programming have their differences. So do Procedural, Aspect Oriented, Imperative, and a few other programming paradigms which I could go on to list (but won't.) Understanding the differences between Functional and Object Oriented programming is just as important as knowing the difference between oil paint and watercolors. They are useful tools that can be used to make beautiful things, but they behave very differently. One of the keys to knowing the reach and scale of these tools is the understanding of the concept of immutability.
"Immutability" means that a thing's state cannot be changed after it is created. For example, the value a variable in a functional language will never change, as opposed to a mutable object in Ruby that can be changed many times over. It's this capacity for modification that makes Object Oriented languages so powerful, and in some cases so challenging. The mutable state of objects in OOP can be misused, leading to code that is labyrinthine and difficult to understand.
Functional programming is more concerned with functions than objects, it separates information from process. In certain cases it takes advantage of caching, so there is no need for a database full of data objects. Functional programming avoids mutable "states" by focusing on input and expressions. If you can change a variable, the program changes "states", functional programming avoids this altogether by isolating behavior into functions that the data is passed through without any mutation. You pass a number into a function, and get a new number out, but the original number has not been changed.
At the 2010 Future of Web Apps (FOWA) conference, Alex Payne summarized the difference between the two paradigms;
Working with object oriented programming is like a movie. You have a cast of characters with a set script. You have directors and producers. It's a time-consuming task and very error prone...Functional programming is more like getting up to a chalkboard and writing an equation. You know how it's gonna work every time. Writing what should be done, instead of how. FP is more like finding and using mathematical abstractions to represent programs. Thinking in an analytical way. FP is value-oriented programming. State is transformed, not mutated.
Despite its complexity, OOP's ability to model real-world objects by encapsulating data and associating behaviors with that data can be a more intuitive approach. We classify things in the real world. We ascribe behaviors and traits to those things, and base our understanding of the world around us based on observation and classification.


I have been participating since 2016 with my account @jack8831. However, I still see one problem that Steemit can not solve yet. What is the problem that Steemit could not solve for three years? It is the ‘low turnout of voters for witness’ that does not fit in DPOS. Steemit community delegated block creation and management to small number of witnesses, making blockchains efficiently, but it faces a number of issues with low voter turnout rates.
The Steem Foundation, which has lost its vision, still hastens to power down. Some witnesses belong to witness pool and can keep their preemptive positions without any competition. I am convinced that the Steemit would suffer from the demands of reform, if these problems remain. I just want to be able to make changes without breaking the existing structure. Therefore, I concluded that it was necessary to raise the voter turnout rate on electing witnesses than anything else.
■ We need to pull up the low turnout
The reason for low voter turnout is that users do not know how to do, are indifferent, or give up. If so, we have to encourage them to communicate well, create interest, and exercise their rights. First of all, voters need to be motivated to participate with interest, it is time to share any compensation to voters now.
The above data shows that the sum of direct and indirect voting rate is only 43.6%! In addition, it seems urgent to raise indirect voter turnout through proxy delegation, which is only 5.7%
■ You can delegate your voting rights to @proxy.token
If it is difficult and cumbersome to decide whom to vote for, you can choose to delegate your rights to others. You just delegate it to someone who will do work, the user who is entitled to it will do the best judgment, vote, and share the selection process and overall results.
Collecting unused your voting right to one voter(account) will make greater influence. The voter who is entrusted with multiple power may demand a few witness candidates something to do. For example, public disclosures of sincere activities, plans and progress reports for steemit development, and some distribution of witness compensation, etc. Some competent witness and witness candidates who challenge the witness position will be willing to be highly evaluated.
■ How to do?
I will show you how to do it. First, I already created an account @proxy.token to get your privileges. Through this account, I will collect power as we communicate with each other. If you are interested in participating, please do the following @proxy.token and delegate your proxy to this account. I will let you know how to do now.
(1) Click on the corner of Steemit website and enter the ‘Vote for Witness’
(2) Type proxy.token on it, and click ‘SET PROXY’ to confirm.
(3) Click ‘OK’ to complete the approval.
■ You will be received PROXY tokens
Those who have delegated proxy to @proxy.token will be given ‘PROXY’ tokens, which is issued with a total of 10 million, in order to prove your proxy delegation and to share possible returns in the future. The PROXY token is for the convenience of these operations and to verify your rights. The PROXY token is issued to Steam Engine, so you must first install the keychain to check up. You can verify the amount of PROXY tokens in your account.
The number of tokens to be paid will have a half-life. This is because tokens were issued in limited quantities, whereas proxies from delegators are constantly changing. Theoretically, a half-life is required to solve infinite fluctuations in limited quantities. In addition, it has also another reason to distribute the quantity in favor of the users who delegates ahead of others. As an example, it could start to have a lasting half-life from the first 2.5 million proxy tokens, following the table below.
  The upvoting power and the proxy (election voting) power are form the same steem power, but they are absolutely different. Therefore, you just delegate the proxy and enjoy posting and upvoting in Steemit world as usual.
■ You can change the Steemit together!
You can change the Steemit with participating the election with proxy delegation. If @proxy.token can collect your proxy and participation, I will work together to identify which witnesses and candidates are needed and helpful in the development of Steemit. I will exercise this power through the @ proxy.token and distribute any compensation to you by PROXY tokens.
By using this method, we will be able to express interest and support for prepared witnesses and witness candidates who want to raise interest and voting turnout. This is just the first step. I will also look forward to your comments and participation through @proxy.token. If you have any comments, please post with #Proxy tag. I will read all your articles carefully. Thank you.
- How to check up the delegated proxy on @proxy.token ?
Go to https://steemyy.com/proxy/ and enter ‘proxy.token’
This page is synchronized from the post: [Notice] I need your participation to raise the low voter turnout rate on electing witness


This module exports a pooled database connection.
The connection is configured here: module:database-config
- Source:
Requires
- module:mongodb
- module:database-config
- module:lib/error-handling
Methods
(static) getConnectionPromise() → {Promise}
Get a connection to the database.
Returns a promise that resolves to a database connection.
This is a single pooled connection for the app.
Configure the database url and connection option settings in the database-config.js
file.
- Source:
Returns:
dbPromise A promise that resolves to a database connection instance of type MongoClient~Db
- Type
- Promise
Example
To be completed.


About me
I am a Software Engineering undergraduate at Sri Lanka Institute of Information Technology(SLIIT)
I've more than 1 year experience in web developing and software development.
Recently I've completed following Projects.
Demo video of the latest Project


by Ibrahim / ibhi
If you think that the internet has changed your life, think again. The IoT is about to change it all over again! - Brendan O’Brien, Chief Architect & Co-Founder, Aria Systems
Install node-RED
$ sudo npm install -g node-red
$ node-red


Package
Class
Tree
Deprecated
Index
Help
PREV NEXT
FRAMES
NO FRAMES
All Classes
C
E
G
H
I
J
M
P
R
S
T
V
C
CLUSTER
- Static variable in class ibis.poolInfo.
PoolInfoProperties
CONNECTION_TIMEOUT
- Static variable in class ibis.poolInfo.
PoolInfo
E
end(boolean)
- Method in class ibis.poolInfo.
Service
G
getAddresses()
- Method in class ibis.poolInfo.
Pool
getCluster()
- Method in class ibis.poolInfo.
PoolInfo
Returns the cluster for the current host.
getCluster(int)
- Method in class ibis.poolInfo.
PoolInfo
Returns the cluster for the host specified by the rank number.
getClusters()
- Method in class ibis.poolInfo.
Pool
getDescriptions()
- Static method in class ibis.poolInfo.
PoolInfoProperties
getHardcodedProperties()
- Static method in class ibis.poolInfo.
PoolInfoProperties
getInetAddress()
- Method in class ibis.poolInfo.
PoolInfo
Returns an IP address of the local machine.
getInetAddress(int)
- Method in class ibis.poolInfo.
PoolInfo
Returns the IP address of the machine with the given rank.
getIPAddressSet()
- Method in class ibis.poolInfo.
PoolInfo
Returns all IP addresses of the local machine, as an IPAddressSet
getIPAddressSet(int)
- Method in class ibis.poolInfo.
PoolInfo
Returns all IP addresses of the machine with the given rank, as an IPAddressSet.
getPoolName()
- Method in class ibis.poolInfo.
PoolInfo
Name of the pool.
H
HOST
- Static variable in class ibis.poolInfo.
PoolInfoProperties
I
ibis.poolInfo
- package ibis.poolInfo
IBIS_PREFIX
- Static variable in class ibis.poolInfo.
PoolInfoProperties
J
join(String, String, int)
- Method in class ibis.poolInfo.
Pool
M
main(String[])
- Static method in class ibis.poolInfo.
PoolInfo
P
Pool
- Class in
ibis.poolInfo
Pool(String, int, boolean)
- Constructor for class ibis.poolInfo.
Pool
POOL_NAME
- Static variable in class ibis.poolInfo.
PoolInfoProperties
POOL_PREFIX
- Static variable in class ibis.poolInfo.
PoolInfoProperties
POOL_SIZE
- Static variable in class ibis.poolInfo.
PoolInfoProperties
PoolInfo
- Class in
ibis.poolInfo
The
PoolInfo
class provides a utility for finding out information about the nodes involved in a closed-world run.
PoolInfo(Properties, boolean)
- Constructor for class ibis.poolInfo.
PoolInfo
PoolInfoProperties
- Class in
ibis.poolInfo
PoolInfoProperties()
- Constructor for class ibis.poolInfo.
PoolInfoProperties
R
rank()
- Method in class ibis.poolInfo.
PoolInfo
Returns the rank number in the pool of the current host.
RESULT_INVALID_SIZE
- Static variable in class ibis.poolInfo.
Service
RESULT_POOL_CLOSED
- Static variable in class ibis.poolInfo.
Service
RESULT_UNEQUAL_SIZE
- Static variable in class ibis.poolInfo.
Service
run()
- Method in class ibis.poolInfo.
Service
S
Service
- Class in
ibis.poolInfo
Service(TypedProperties, VirtualSocketFactory)
- Constructor for class ibis.poolInfo.
Service
size()
- Method in class ibis.poolInfo.
PoolInfo
Returns the number of nodes in the pool.
T
toString()
- Method in class ibis.poolInfo.
PoolInfo
Returns a string representation of the information in this
PoolInfo
.
toString()
- Method in class ibis.poolInfo.
Service
V
VIRTUAL_PORT
- Static variable in class ibis.poolInfo.
Service
C
E
G
H
I
J
M
P
R
S
T
V
Package
Class
Tree
Deprecated
Index
Help
PREV NEXT
FRAMES
NO FRAMES
All Classes


--- layout: post title: The Daily Commit 2 date: '2013-05-31T15:03:00-07:00' tags: - programming - frombrett tumblr_url: http://beekley.xyz/post/51832417832/the-daily-commit-2 ---
Added the function to place citizen in the plot they were randomly assigned to. Unfortunately, I’m getting some TypeErrors elsewhere. It’s pretty late and I think these will have to be addressed at a future date.


Libc So 6 Freebsd Download
Error Lib64 Libc So 6 Version Glibc 2 14 Not Found On Red Hat Rhel 6 5 Linux Issue 192 Microsoft Napajs Github
Centos6 5 System Libc So 6 Version Glibc 2 15 Not Found Processing Programmer Sought
Linux Installation Mysql Appears Libc So 6 Is Needed By Mysql Server Programmer Sought
Error When Executing Command In Centos6 5 Libc So 6 Version Glibc 2 14 Not Found Programmer Sought
Solve Lib64 Libc So 6 Version Glibc 2 14 Not Found Linux Environment Programmer Sought
U01 Perl Bin Perl Lib64 Libc So 6 Version Glibc 2 14 Not Found Required By U01 Perl Bin Perl Alphaora
How To Install Screen Command On Centos 8 Rhel 8 Globedrill
Lic So 6 Error 32bit Crostini
Installing The Linux Library On A 64 Bit In Preparation For The Ms
Centos6 4 Upgrade Glibc 2 14 Programmer Sought
Libc So 6 Glibc 2 14 64bit Rhel 6 Download
Error You Are Missing The Following 32 Bit Libraries And Steam May Not Run Libc So 6 Issue 5511 Valvesoftware Steam For Linux Github
Vi Command Not Found How To Install Vi On Centos 8 Globedrill
How To Use Yum Command On Centos Rhel Nixcraft
Let S Play X86 Games Games Clockworkpi
삽질일지 Libstdc So 6 Glibcxx 3 4 15 64bit 네이버 블로그
Release Linux Musl Builds Issue 1658 Denoland Deno Github
Install Glibc 2 14 Under Linux Resolve Glibc 2 14 Not Found Problem Programmer Sought
Shared Hosting Lib64 Libc So 6 Version Glibc 2 14 Not Found
Installing Emc Dell Networker 9 On Centos 7 Blog By Nitin J Mutkawoa
How To Update Glibc 2 17 Newer Version On Centos 6 X
Error While Loading Shared Libaries Libc So 6 Mistakenly Deleted Can Not Start At Boot Programmer Sought
Steam Missing The Following 32 Bit Libraries Libc So 6 Youtube
Networker Installation In Linux
Reprint Lib X86 64 Linux Gnu Libc So 6 Version Glibc 2 17 Not Founding Solution
Solve The Problem Of Libc So 6 Version Glibc 2 14 Not Found Programmer Sought
18 Distributing Open Software Rpm Command 1 Computer
Download Dependencies For A Rpm


| |
More information about mod_qos:
Build
mod_qos requires OpenSSL, PCRE, threading and shared memory support. mod_qos
was originally developed and fully tested for Apache version 2.2
MPM worker
binaries, but works with Apache version 2.4 as well. The module is optimized to be used in a
reverse proxy
server.
Notes: You should definitely 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 command
httpd -l must list the mod_so.c module.
The following command compiles the module and installs mod_qos into the
server's modules directory.
cd mod_qos-11.59/apache2
apxs -i -c mod_qos.c -lcrypto -lpcre
cd ../..
|
If the necessary header files of OpenSSL, PCRE, etc. cannot be found, add
the -I option to the apxs command 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 -L option 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 QSLog directive. |
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 QSLog directive. |
Event |
| |
QSLOG_AVERAGE |
Defines the environment variable which shall be used for the "average" (a)
within the format string used by the QSLog directive. |
QS_AllConn |
| |
QS_LOG_REPEAT |
Counter used to define how many repetitive messages are summarized. |
20 |
| |
QS_REQ_RATE_TM |
Default for the QS_SrvSampleRate directive. |
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, PCRE,
libpng, and OpenSSL.
cd mod_qos-11.59/tools
./configure
make
|
Source Code
mod_qos is available for Apache version 2.2 respectively 2.4.
Configuration
Configuration 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 all QS_Client*
directives may be used outside of virtual host configurations only.
The QS_LogOnly on directive 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 Control
The 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. A
QS_LocRequestLimit* rule may be used in parallel to a
QS_LocRequestPerSecLimit* and/or
QS_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_LocRequestLimitMatch
only (you must use the very same regex pattern with the
QS_LocRequestPerSecLimitMatch
and QS_LocRequestLimitMatch
directive) 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_LocRequestLimitMatch
only (you must use the very same regex pattern with the
QS_LocKBytesPerSecLimitMatch and
QS_LocRequestLimitMatch directive)
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_LocRequestLimitMatch
directives.
-
QS_LocRequestLimitDefault <number>
Defines the
default limitation for the maximum of concurrent requests per-location
for those locations not defined by any
QS_LocRequestLimit
directive. 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_LocRequestPerSecLimitMatch
directive. 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 with
QS_LocRequestLimit only (you
must use the same location for both directives) to avoid too many
concurrent requests.. Has lower priority than
QS_LocRequestPerSecLimitMatch .
-
QS_LocKBytesPerSecLimit <location> <number>
Throttles the download bandwidth to the defined
kbytes per second. Works simlar as the
QS_LocKBytesPerSecLimitMatch
directive slowing down HTTP responses by adding a delay to each response.
By default, no limitation is active. This directive should be used in
conjunction with QS_LocRequestLimit only
(you must use the same location for both directives) to avoid too many
concurrent requests.. Has lower priority than
QS_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 Page
The QS_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_ErrorResponseCode and
QS_ErrorPage directives).
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* or
QS_RequestHeaderFilter
directive.
413: when limiting the max. body data length by the
QS_LimitRequestBody directive.
500: for requests denied by any other directive.
Privileged Users
Additional 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:
-
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_VipHeaderName
directive). Alternatively, a new session is started when detecting an
authenticated user, see QS_VipUser .
The QS_Session*
directives are used to set session attributes.
-
Request: The
QS_VipRequest
process environment may be evaluated by mod_qos rules. This
variable is set automatically when receiving a valid mod_qos
session cookie. The QS_VipRequest
variable may also be set by configuration using a QS_SetEnvIf*
or SetEnvIf
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 , and
QS_VipUser directives are used
to define when an IP address should be marked as a VIP user.
Directives:
-
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_VipUser
Creates 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_VipHeaderName directive.
-
QS_VipIPUser
Marks 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_VipIPHeaderName directive.
-
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:
| 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 |
| | |
Notes:
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.
Variables
Environment 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:
-
QS_ErrorPage=<URL>
Defines the error page overriding the setting made by the
QS_ErrorPage directive.
-
QS_VipRequest=yes
Disables some restrictions for this request (see privileged Users).
Requires the definition of a VIP header using the
QS_VipHeaderName directive
(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_Event
The variable processed by the QS_ClientEventPerSecLimit directive.
-
QS_Block[=<number>]
Variable processed by the QS_ClientEventBlockCount
directive.
The optional number value defines the penalty points to
increase the counter (default is 1).
-
QS_Limit[=<number>]
(Default) variable processed by the
QS_ClientEventLimitCount
directive.
The optional number value defines the penalty points to
increase the counter (default is 1).
-
*_Clear
The counter of the variable processed by the
QS_ClientEventLimitCount
directive is reset if you set the same variable suffixed by _Clear ,
e.g. QS_Limit_Clear .
-
*_Decrement
The counter of the variable processed by the
QS_EventLimitCount ,
QS_CondEventLimitCount ,
QS_ClientEventLimitCount ,
QS_CondClientEventLimitCount , and
QS_ClientEventBlockCount
directives
is decremented by the value set in the same variable suffixed by _Decrement ,
e.g. QS_Limit_Decrement=1 decrements the value of the QS_Limit
variable of the corresponding
QS_ClientEventLimitCount
rule by 1. The variable is evaluated at the end of the request processing.
-
QS_Serialize
Variable processed by the QS_ClientSerialize
directive.
-
QS_SrvSerialize
Variable processed by the QS_SrvSerialize
directive.
-
QS_Cond
Variable processed by the QS_CondLocRequestLimitMatch ,
QS_CondEventLimitCount , and
QS_CondClientEventLimitCount directives.
-
QS_EventRequest
Variable processed by the QS_ClientEventRequestLimit directive.
Variables set by mod_qos which may be processed by conditional or event based
rules, e.g.,
QS_CondLocRequestLimitMatch :
-
QS_SrvConn
Number of concurrent
connections for this server/virtual host. Value is set
when using either the QS_SrvMaxConn ,
QS_SrvMinDataRate ,
QS_SrvMaxConnClose , or
QS_ClientGeoCountryDB
directive.
Note: value is calulcated when the client establishes the connection
and remains the same for all HTTP requests performed on this connection.
-
QS_AllConn
Number of all concurrent connections for this Apache instance. Value is set
when using either the QS_SrvMaxConn ,
QS_SrvMinDataRate ,
QS_SrvMaxConnClose , or
QS_ClientGeoCountryDB
directive.
Note: value is calulcated when the client establishes the connection
and remains the same for all HTTP requests performed on this connection.
-
QS_IPConn
Number of IP connections open from the current IP address. Variable is
available when using the QS_SrvMaxConnPerIP
directive.
Note: value is calulcated when the client establishes the connection
and remains the same for all HTTP requests performed on this connection.
-
QS_ClientLowPrio
The 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_IsVipRequest
Variable is set when detecting a VIP request
(either by cookie, IP address status, valid user, etc.). May be used by
various event based directives.
-
*_Counter
The counter values of the variables used by the
QS_ClientEventLimitCount
and QS_EventLimitCount
directive are stored within the variable whose name is suffixed by
_Counter , e.g. QS_Limit_Counter when limiting
QS_Limit events.
-
QS_ErrorNotes
The error code (number only) of a mod_qos log message
that has occured during a request.
-
QS_Country
ISO 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 <IP_ADDRESS> 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
|
Conditional Rules
Conditional rules are only enforced if the QS_Cond
variable matches the specified pattern.
-
QS_CondLocRequestLimitMatch <regex> <number> <condition>
Rule works similar to QS_LocRequestLimitMatch
but it is only enforced for requests whose QS_Cond
variable 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_CondLocRequestLimitMatch rule is evaluated per request.
-
QS_CondEventLimitCount <env-variable> <number> <seconds> <pattern>
Same as QS_EventLimitCount but
requests are only blocked if the value of the
QS_Cond
variable 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_ClientEventLimitCount
but requests are only blocked if the value of the QS_Cond
variable 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
|
Events
mod_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.
-
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 enviroment 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_EventRequestLimit
only (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_CondEventLimitCount
if you want to enforce a rule under certain conditions only.
- The event counter can be decremented by setting the environment
<env-variable>_Decrement .
Mulpiple built-in directives may be used to set or detect events (additional
event variable processing could be configured using
mod_setenvif 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 ..$9
within 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 specifed 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 , and multipart/mixed )
and sets the defined process variable (quite similar to the
QS_SetEnvIfQuery directive).
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 the
SetEnvIf
or SetEnvIfPlus
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 the QS_LimitRequestBody directive
when using QS_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 the
SetEnvIf
or SetEnvIfPlus
directive.
You should limit the allowed size of HTTP requests message body
using the QS_LimitRequestBody
directive 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_ClientEventBlockCount or
QS_ClientEventLimitCount
directive.
When using the special variable QS_Block , its
value is set to "1" by default. There are also three "special codes" available to
set the QS_Block event:
-
QS_SrvMinDataRate may be used
to set QS_Block events in order to limit the
allowed number of QS_SrvMinDataRate
rule violations.
-
QS_SrvMaxConnPerIP may be used
to increment the QS_Block
event when closing connections due to the reach of the limitation configured
by the QS_SrvMaxConnPerIP directive.
-
NullConnection detects connections
which are closed even no HTTP request has been received.
Note: The NullConnection event may happen silently (no log
message) expect when using LogLevel "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.
-
BrokenConnection may 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_SetEnvIfResBodyIgnore
environment 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 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> [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 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_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 Filter
These 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_HOOKS to enable the decoding hooks defined
in mod_qos.h if 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 , and
QS_DenyQuery directives.
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* and QS_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_PermitUri
pattern are allowed. If a QS_PermitUri pattern 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 the qsfilter2
utility to generate rules based on access log files.
-
QS_DenyInheritanceOff
Disables inheritance of QS_Deny* and QS_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 (whitelist). Custom
rules (additional headers or different pattern/size definitions) may be
added using the
QS_RequestHeaderFilterRule
directive.
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 LimitRequestFieldsize
but 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 blacklist rules (delete unwanted headers) using the
QS_UnsetReqHeader or
QS_UnsetResHeader directive.
-
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 , and multipart/mixed . The content type
application/json may 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 the
QS_DenyQuery and
QS_PermitUri directives.
-
QS_DenyQueryBody 'on|'off'
Enables request body data filtering for the
QS_DenyQuery directive.
-
QS_PermitUriBody 'on|'off'
Enables request body data filtering for the
QS_PermitUri directive.
-
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).
Set the QS_DeflateReqBody variable if the request body data has to
be deflated (compressed data) using
mod_deflate .
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>
|
You may enable request body filtering for arbitrary content types:
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> [<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 (don't use them 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_KeepAliveTimeout
and QS_MaxKeepAliveRequests
environment 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_SrvMaxConnPerIP directive
to ignore (if set to "on") the VIP status of
clients. Default is "off", which means that QS_SrvMaxConnPerIP gets
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_ClientPrefer directive).
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 the MaxClients setting.
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 the
QS_SrvMinDataRate rule 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_SrvMinDataRate but enforcing a
minimal upload (reading request) throughput only.
-
QS_SrvDataRateOff
Disables the QS_SrvMinDataRate or
QS_SrvRequestRate enforcement
for a virtual host.
-
QS_SrvMinDataRateOffEvent '+'|'-'<env-variable>
Disables the QS_SrvMinDataRate or
QS_SrvRequestRate enforcement
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_TM while 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_SrvMinDataRate rule for clients opening unused TCP pre-connections
which might happen if Apache's
TimeOut directive is set to higher value than this sample rate.
-
QS_SrvMinDataRateIgnoreVIP 'on'|'off'
Tells the QS_SrvMinDataRate directive
to ignore (if set to "on") the VIP status of
clients. Default is "off", which means that QS_SrvMinDataRate gets
disabled for VIPs.
-
QS_SrvSerialize 'on'|'off' [<timeout>]
Ensures that not more than one request having the
QS_SrvSerialize
variable 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 bandwith limitation on a per connection
basis but you might use the
RATE_LIMIT filter
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_ClientEventLimitCount
events 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_EventRequest variable set.
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.
-
QS_ClientEventPerSecLimit <number>
Defines how often a client may cause a
QS_Event
per second. Such events are requests having the
QS_Event variable set, e.g., defined by
using the SetEnvIf directive.
The rule is enforced by adding a delay to requests causing
the event (similar to the QS_LocRequestPerSecLimit
directive).
-
QS_ClientEventBlockCount <number> [<seconds>]
Defines the maximum number of QS_Block
events 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_Limit by 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_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.
You might even use the SetHashHeaderPlus
directive to create a hash representing a client using arbitrary HTTP
request attributes.
- The current value of this counter is stored within the variable suffixed
by
_Counter , e.g. QS_Limit_Counter for further
processing by other rules.
- The remaining time (in seconds) is stored within the variabled suffixed
by
_Remaining , e.g. QS_Limit_Remaining to 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_CondClientEventLimitCount
if you want to enforce a rule under certain conditions only.
-
QS_ClientSerialize
Serializes requests having the
QS_Serialize
variable 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. The server
continues dropping more and more clients
(also those with few penalty points) the higher the number of connections
grows.
Use the
QS_VipHeaderName or
QS_VipIPHeaderName
directive in order to identify VIP clients.
The distinction between high and low priority clients is made
based on penality points which are calculated based of these attributes:
- Data transfer behavior (clients sending data slowly / their transfer rate) (0x01).
- Accessing "unusual" content types (see
QS_ClientTolerance
and QS_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).
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.
A low priority flag is cleared after 24h hours. Clients identified by
QS_SrvMaxConnExcludeIP
are 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_ClientPrefer directive. 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. Can only be used in conjunction with the
QS_ClientPrefer directive.
QS_ClientTolerance defines
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 the
QS_Status log 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:
-
Double quoted beginning IPv4 number of the address range, e.g. "1052272128" for <IP_ADDRESS>
-
Double quoted ending IPv4 number of the address range, e.g. "1052272543" for <IP_ADDRESS>.
-
Double quoted ISO 3166 country code, e.g. "FR" for France.
The QS_Country variable contains
the country code for the client's IP address.
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.
-
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:
# 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 Messages
Error 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's error-notes note
as well as the QS_ErrorNotes
variable) 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
BrokenConnection
has 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 ,
or QS_EventRequestLimit directive.
-
mod_qos_con
This event shows the number of
concurrent connections to this server. Only available if the directive
QS_SrvMaxConn
is 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']
directive.
Options of the QS_UserTrackingCookieName directive are:
- The
name argument defining the name of the
user tracking cookie.
- The
path specifies 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_ENFORCEMENT environment 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.
domain defines optionally the domain attribute for
the Set-Cookie header.
- The
session flag indicates that a short lived (per
session) cookie shall be creaed which won't be stored by the browser
permanently.
Notes:
QS_UserTrackingCookieName ignores the
QS_LogOnly
directive.
- The cookie is secured by the
QS_SessionKey
and 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_ID
environment variable as well, in order to correlate errors
to access log messages.
-
QS_ConnectionId
Connecton 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 qslog tool, 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 the qslog
utility 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 CustomLog directive,
you may use the QSLog directive of mod_qos alternatively. This
allows you to configure a single log file for your Apache instance (globally,
not per virtal 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.
<Location /qos>
SetHandler qos-viewer
</Location>
|
A machine-readable version of the status information is available when using
the request query string auto , e.g.,
http://your.server.name/qos?auto . The page updates itself
automatically every 10 seconds if you add the request
query string refresh , 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 on and are using any
client level limitation using
QS_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_HOOK to disable its regisration to
the status page rendered by mod_status.
Use the directive QS_DisableHandler on to 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).
The directive QS_Status 'on'|'off' may be used to enable a
status log message (mod_qos(200)) written to the Apache server's
ErrorLog . 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.
<Location /qos/console>
SetHandler qos-console
</Location>
|
Access a location where you have enabled the qos-console handler
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 also QS_ClientEventBlockCount .
unblock : clears the block attribute of the client.
limit : denies requests
from the client IP for the configured period of time, see also
QS_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 address parameter in order to get a list of all available clients (dump).
- event=<name>
Specifies the event name of the
QS_ClientEventLimitCount
directive counter which shall be
shown or modified (used in conjunction with the limit ,
unlimit , inclimit , and search action).
Default is QS_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 qsexec
is 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 <IP_ADDRESS>:
http://your.server.name/qos/console?action=setvip&address=<IP_ADDRESS>
- Clears the QS_Limit counter for the IP <IP_ADDRESS>:
http://your.server.name/qos/console?action=unlimit&address=<IP_ADDRESS>&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=<IP_ADDRESS>
Utilities
mod_qos provides optional tools for log data processing and analysis:
- qsdt
Simple tool
to measure the elapse time between related log messages.
- qsexec
Command execution
triggered by patterns within log files.
- qsfilter2
Rule generator. Creates QS_Permit* directives and rule patterns
from audit log files.
- qsgeo
Adds the country code
for the client IP address within a log file.
- qsgrep
Searches a file for a
pattern and prints the data in a new format.
- qslog
A real time
TransferLog/CustomLog
data analyzer. It reads the per request log data from stdin and generates
statistic records every minute.
- qslogger
Shell command
interface to the syslog(3) system log module.
- qspng
Creates graphics (png
images) from the output of qslog .
- qsre
Regular expression (pcre)
pattern match test tool.
- qsrespeed
Compares the
expected processing time per regular expression.
- qsrotate
Log rotation tool
similar to Apache's rotatelogs .
- qssign
A log data integrity
check tool. It reads log data from stdin (pipe) and writes the signed data
to stdout adding a sequence number and signatur to ever log line.
qssign.rb is a Logstash filter
plugin which may be used to verify the signatures of log messages in real time.
- qstail
Shows the end of a log
file beginning at a defined pattern.
Sample 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 qslog tool may be used
to analyze your log files in order to idenitify "slow" resources by
using the -pu or -puc option.
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. mod_qos will then calculate the necessary delay time to be added
to each requests accessing this resource in order to achive the defined
limitation.
Example:
Alernatively, if you need to reduce the number of processed requests
per time to a very low value, you might add a constant delay to
each request and process only one of them at the same time. However,
this will delay ever 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 (LimitDownloadCounter is
the counter to use while the
LimitDownloadNow pattern 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_EventLimitCount directive,
or on a per client IP basis using the
QS_ClientEventLimitCount
directive.
Example:
# allows a single IP addess 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
|
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
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_CondEventLimitCount
directive 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_SrvMaxConnPerIP
directive 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
|
|


#include <lmdes.h>
Definition at line 117 of file lmdes.h.
Definition at line 121 of file lmdes.h.
Referenced by load_lmdes(), and print_mdes().
Definition at line 119 of file lmdes.h.
Referenced by load_lmdes().
Definition at line 122 of file lmdes.h.
Definition at line 123 of file lmdes.h.
Definition at line 120 of file lmdes.h.


D Block Europe Join DigDat On "New Dior"
D Block Europe and DigDat team up for a banger.
by Aron A.New Dior
DigDat Feat. D Block Europe
Editor Rating: HOTTTTT
User Rating: n/a - 0% (0)
DigDat has teamed up with one of the hottest duos in the U.K. right now, D Block Europe, for the new single, "New Dior." DigDat has been making waves this year following his single, "Airforce" entering the UK Singles charts. Their new single, "New Dior" is a dark banger, treading closer to the regional UK drill sound that's been making noise in the past year. Young Adz holds down a syrupy hook before DigDat and DirtBike LB swing in on the verses.
D Block Europe have claimed serious dominance in the U.K. this year. With collaborations with Dave, Lil Baby, AJ Tracey, and more on their recently released PTSD, they've shown that they can hold their own among international giants.
Peep the song below.
Quotable Lyrics
Bank rolls, bank-bank rolls, hella VVS' on me
Cali weed, promethazine, and I keep a weapon on me
Took her Dior, bought the store, she on me
Flew her abroad, hit it raw, she on me


My tools
GIT
HTML
CSS
Bootstrap
Javascript
jQuery
Node JS
Mailchimp
Figma
XD
Photoshop
Illustrator
Trello
Slack
//Currently learning
React
Sass
//Front End Dev and 3D Generalist
I'm a Front End Developer based in Mexico
I started my front-end developer journey on August of 2020. Since then I have been learning everyday something new.
GIT
HTML
CSS
Bootstrap
Javascript
jQuery
Node JS
Mailchimp
Figma
XD
Photoshop
Illustrator
Trello
Slack
//Currently learning
React
Sass
NOVEMBER 2020 - CURRENTLY WORKING HERE
Front End and 3D Generalist
BOWHEAD HEALTH
//Remember to remove 👇
//Work in progress
//Feedback is welcome!
Coffee
Code
Music


Police appeal for dash cam footage of fatal crash
Police are appealing for dash cam footage taken at the time Christchurch cyclist Fyfa Dawson was killed after being hit by a truck.
Miss Dawson, 19, died after a concrete truck hit her about 8am on October 30 in a 30km/h area as it made a turn on Springs Rd near Halswell Junction Rd. She was working at Benny's Barber Shop in Sydenham.
Police want to hear from anyone with dash cam footage who may have been travelling north at or about this time. Major road works were being undertaken around the Halswell motorway overbridge.
Detective Sergeant Brian Cameron said it is important those motorists get in touch whether or not they witnessed the incident involving a concrete truck and a cyclist.
“Footage of the traffic flow in that area at that time would be helpful to the investigation team as they continue their work to establish the cause of the tragic incident.
"It may demonstrate the traffic ebb and flow at the time - even if the footage doesn’t show anything directly related to the crash, please allow police the opportunity to determine its evidential value.”
- If you believe you have any information that may assist, email Detective Sergeant Cameron at brian.cameron@police.govt.nz.


This field is requered
This field is incorect
Minimum length of field is {{ personalNumber.errors.minlength.requiredLength }}
{{ bookForm.value | json }}


|
An archive of disturbing illustration
Certain people (including parents and schoolteachers) have complained to us and stated that rotten.com should not be "allowed" on the net, since children can view images on our site. One US schoolteacher wrote us a very angry email that complained some of her students had bookmarked images on this site, that our site shouldn't be on the net, and other claptrap. This is our response. The net is not a babysitter! Children should not be roaming the Internet unsupervised any more than they should be roaming the streets of New York City unsupervised.  Rotten dot com serves as a beacon to demonstrate that censorship of the Internet is impractical, unethical, and wrong. To censor this site, it is necessary to censor medical texts, history texts, evidence rooms, courtrooms, art museums, libraries, and other sources of information vital to functioning of free society. Nearly all of the images which we have online are not even prurient, and would thus not fall under any definition of obscenity. Any images which we have of a sexual nature are in a context which render them far from obscene, in any United States jurisdiction. Some of the images may be offensive, but that has never been a crime. Life is sometimes offensive. You have to expect that. The images we find most obscene are those of book burnings. Please remember that no child has access to the Internet without the active consent of an adult. And absolutely no child should be left on the Internet alone. Supervision of children remains the responsibility of parents and teachers, as it always has and always will.
|


HAND WRITING METABOLISM
Project
final presentation
Theme : LIFE CAN BE INFORMATION MATERIAL?
Use microorganism as material and information.
Previous studies
90 petabytes of data into 41 grams of DNA.
Over five million bits of data were stored and all the DNA files reproduced the information between 99.99% and 100% accuracy encoding the data in a series of overlapping short oligonucleotides.
DNACloud: Encoding computer files to DNA data
Method for random access of data items stored in DNA.
Fully automated system to encode and decode data in DNA.
Project
1. Write down characters and translate data to DNA code
Text unicode data Coordinate data of handwriting
↓
Binary data 0 0 1 1 0 1 0 0 1 …..
↓
DNA data A T T G C C A …..
2.Genetically inject DNA data into microbe DNA, and culture them.
DNA syntehtize
- Phosphoramidite method
- DNA synthesizer
- Order DNA
DNA transformation
- Create vector with synthetic DNA fragment
- Transformation by homologous recombination
3.Sequencing DNA in microbe and pick out the data
4.Regenerate handwriting information
Written on April 12, 2019


I create things in both the digital and physical realms. I am equally comfortable bending both copper and CSS to my will. In short, I design web sites. I am a trained metalsmith. And I do both professionally. I rant about politics and current events, too, but that's more of a hobby-- except when it comes out in my artwork (as in my MFA Thesis Show).
When I first started studying metalsmithing, I also studied graphic design. I first started playing with web design around 2001, when I was dragged into it kicking & screaming as an "Accidental Tech." Since July 2014, I've been bringing my Web Site Design skills up to date through the fantastic Code Oregon program, after spending most of the last twelve years earning both my Master of Arts and my Master of Fine Arts in Jewelry/Metalsmithing.
In regards to web design, I'm seriously focused on User Experience(UX). To me, UX is simply following the same functional design principles I use when creating jewelry or functional metalwork. I have a rather detailed essay explaining my design philosophy and how metalsmithing relates to it but the short version is that proper UX design follows the same functional design principles I use in my metalwork, just applied to a different technology. It doesn't matter how pretty or flashy a website is if no one can figure how to get to the information they need or get from one page to another.
I am also very interested in the idea of wearable tech- specifically, how to take these fascinating technologies and design them in such a way that their aesthetic design is as well considered as their functions, if not more so. Rubber bands may look alright in the gym but they don't look as nice with your little black dress. In other words, I want to make the tech look as cool on the outside as it is on the inside. I'm currently working up some designs for my little FitBit & will start posting pictures of my design process as I go along.
As a metalsmith, I spend my time in my studio pounding on metal, forming and shaping it into a variety of objects from production jewelry to one-of-a-kind statement pieces to functional hollowware to small-scale sculpture and what I think of as "Curiosities". Feel free to browse through my various galleries to see what I've been up to at SharonSmithMetals.com. All the jewelry & metalwork on the site was designed and fabricated by me.
Along with ranting about politics, I am very into original, indie, alternative, and punk bands and nearly always have music playing while I work. I love discovering new bands and could happily spend every night at a club. Current local Portland favorites are NTNT, Murderbait, and DeadCult- a group I first heard through the walls of my studio when they were playing the Lovecraft Bar, which happens to be next door.
I'm an avid reader and will read just about anything I can get my hands on. In fact, I told my family that the main reason I chose to move to Portland was so I could hang out in Powell's. I wasn't entirely joking. Mostly, I read a lot of general fiction, classic fiction, urban fantasy/magical realism/mythic fiction (think Neil Gaiman, Charles De Lint, or the Dresden Files as opposed to epic/high fantasy like the Wheel of Time or Shannara books. Although I do love G.R.R. Martin), speculative fiction, horror, nonfiction about folklore & mythology, social commentary, graphic design, art, web design, and history. Like I said, avid reader.


BREAKING: PDP candidate, Musa Wada casts his vote
The Gubernatorial candidate of the People’s Democratic Party in the 2019 Gubernatorial election, Mr Musa Wada, has Voted.
Wada was unable to vote in his polling due to malfunctioning of the card readers, but later voted at another polling unit.
Details Shortly…


venus / venusbackend.simulator.cache / Cache / <init>
<init>
Cache(c: CacheHandler)
Parameters
capacity
- the size in words of the cHandler
associativity
- the number of blocks in each set
blocksize
- the size in bytes of each block
memory
- a reference to main memory


We offer solutions that address business, institution, government and individual problems.
Our publishing unit is characterized by decades of experience in Desktop publishing, printing and graphics design .
Our consulting unit covers trainings, conferences, seminars, workshops in areas like information, communication, knowledge management, business development and ICT applications in government, medicine, public service


Home
Categories
Cars
Fashion
Electronics
Others
Towns
Sofia
Varna
Plovdiv
Ruse
Sign Out
Sign In
×
Register
Sofia
Varna
Plovdiv
Ruse
Other
Sign Up