mirror of
https://github.com/owasp-modsecurity/ModSecurity.git
synced 2025-11-15 17:12:14 +03:00
Fix spelling of persistent
@@ -3111,7 +3111,7 @@ SecAction phase:1,id:116,nolog,pass,initcol:ip=%{REMOTE_ADDR}
|
||||
|
||||
Collections are loaded into memory on-demand, when the initcol action is executed. A collection will be persisted only if a change was made to it in the course of transaction processing.
|
||||
|
||||
See the "Persistant Storage" section for further details.
|
||||
See the "Persistent Storage" section for further details.
|
||||
|
||||
== log ==
|
||||
'''Description:''' Indicates that a successful match of the rule needs to be logged.
|
||||
@@ -4202,8 +4202,8 @@ Macro expansion can be used in actions such as initcol, setsid, setuid, setvar,
|
||||
|
||||
Some values you may want to expand include: TX, REMOTE_ADDR, USERID, HIGHEST_SEVERITY, MATCHED_VAR, MATCHED_VAR_NAME, MULTIPART_STRICT_ERROR, RULE, SESSION, USERID, among others.
|
||||
|
||||
= Persistant Storage =
|
||||
At this time it is only possible to have five collections in which data is stored persistantly (i.e. data available to multiple requests). These are: GLOBAL, RESOURCE, IP, SESSION and USER.
|
||||
= Persistent Storage =
|
||||
At this time it is only possible to have five collections in which data is stored persistently (i.e. data available to multiple requests). These are: GLOBAL, RESOURCE, IP, SESSION and USER.
|
||||
|
||||
Every collection contains several built-in variables that are available and are read-only unless otherwise specified:
|
||||
#'''CREATE_TIME''' - date/time of the creation of the collection.
|
||||
@@ -4220,7 +4220,7 @@ To create a collection to hold session variables (SESSION) use action setsid. To
|
||||
|
||||
; Note : ModSecurity implements atomic updates of persistent variables only for integer variables (counters) at this time. Variables are read from storage whenever initcol is encountered in the rules and persisted at the end of request processing. Counters are adjusted by applying a delta generated by re-reading the persisted data just before being persisted. This keeps counter data consistent even if the counter was modified and persisted by another thread/process during the transaction.
|
||||
|
||||
; Note : ModSecurity uses a Berkley Database (SDBM) for persistant storage. This type of database is generally limited to storing a maximum of 1008 bytes per key. This may be a limitation if you are attempting to store a considerable amount of data in variables for a single key. Some of this limitation is planned to be reduced in a future version of ModSecurity.
|
||||
; Note : ModSecurity uses a Berkley Database (SDBM) for persistent storage. This type of database is generally limited to storing a maximum of 1008 bytes per key. This may be a limitation if you are attempting to store a considerable amount of data in variables for a single key. Some of this limitation is planned to be reduced in a future version of ModSecurity.
|
||||
|
||||
= Miscellaneous Topics =
|
||||
|
||||
|
||||
Reference in New Issue
Block a user