bring Phases descriptions more up to date

Reference-Manual-(v3.x).mediawiki

@@ -1071,19 +1071,14 @@ In the two examples configurations shown, SecWebAppId is being used in conjuncti
 '''NOTE:''' You must enable this directive if you need to use the <code>@validateSchema</code> or <code>@validateDtd</code> operators.
 
 = Processing Phases =
-ModSecurity 2.x allows rules to be placed in one of the following five phases of the Apache request cycle:
+ModSecurity 3.x allows rules to be placed in one of the following five phases of HTTP request:
 *Request headers (REQUEST_HEADERS)
 *Request body (REQUEST_BODY)
 *Response headers (RESPONSE_HEADERS)
 *Response body (RESPONSE_BODY)
 *Logging (LOGGING)
 
-Below is a diagram of the standard Apache Request Cycle. In the diagram, the 5 ModSecurity processing phases are shown.
-
-[[http://www.modsecurity.org/graphics/modsec-rotation.jpg]]
-
-
-In order to select the phase a rule executes during, use the phase action either directly in the rule or in using the SecDefaultAction directive:
+In order to select the phase a rule executes during, use the phase action in the rule or in the SecDefaultAction directive:
 <pre>
 SecDefaultAction "log,pass,phase:2,id:4"
 SecRule REQUEST_HEADERS:Host "!^$" "deny,phase:1,id:5"
@@ -1093,22 +1088,19 @@ SecRule REQUEST_HEADERS:Host "!^$" "deny,phase:1,id:5"
 
 ; Note : The LOGGING phase is special. It is executed at the end of each transaction no matter what happened in the previous phases. This means it will be processed even if the request was intercepted or the allow action was used to pass the transaction through.
 == Phase Request Headers ==
-Rules in this phase are processed immediately after Apache completes reading the request headers (post-read-request phase). At this point the request body has not been read yet, meaning not all request arguments are available. Rules should be placed in this phase if you need to have them run early (before Apache does something with the request), to do something before the request body has been read, determine whether or not the request body should be buffered, or decide how you want the request body to be processed (e.g. whether to parse it as XML or not).
+Rules in this phase are processed immediately after the request headers have been received. At this point the request body has not been read yet, meaning not all request arguments are available. Rules should be placed in this phase if you need to have them run early, to do something before the request body has been read, or decide how you want the request body to be processed (e.g. whether to parse it as XML or not).
 
-; Note : Rules in this phase can not leverage Apache scope directives (Directory, Location, LocationMatch, etc...) as the post-read-request hook does not have this information yet. The exception here is the VirtualHost directive. If you want to use ModSecurity rules inside Apache locations, then they should run in Phase 2. Refer to the Apache Request Cycle/ModSecurity Processing Phases diagram.
 
 == Phase Request Body ==
-This is the general-purpose input analysis phase. Most of the application-oriented rules should go here. In this phase you are guaranteed to have received the request arguments (provided the request body has been read). ModSecurity supports three encoding types for the request body phase:
-*'''application/x-www-form-urlencoded''' - used to transfer form data
-*'''multipart/form-data''' - used for file transfers
-*'''text/xml''' - used for passing XML data
+This is the general-purpose input analysis phase. Most of the application-oriented rules should go here. In this phase you are guaranteed to have received the request arguments (provided the request body has been read). ModSecurity supports four types of request body parsing:
+*'''application/x-www-form-urlencoded'''
+*'''multipart/form-data'''
+*'''xml'''
+*'''JSON'''
 
-Other encodings are not used by most web applications.
-
-; Note : In order to access the Request Body phase data, you must have SecRequestBodyAccess set to On.
 
 == Phase Response Headers ==
-This phase takes place just before response headers are sent back to the client. Run here if you want to observe the response before that happens, and if you want to use the response headers to determine if you want to buffer the response body. Note that some response status codes (such as 404) are handled earlier in the request cycle by Apache and my not be able to be triggered as expected. Additionally, there are some response headers that are added by Apache at a later hook (such as Date, Server and Connection) that we would not be able to trigger on or sanitize. This should work appropriately in a proxy setup or within phase:5 (logging).
+This phase takes place just before response headers are sent back to the client. Run here if you want to observe the response before that happens.
 
 == Phase Response Body ==
 This is the general-purpose output analysis phase. At this point you can run rules against the response body (provided it was buffered, of course). This is the phase where you would want to inspect the outbound HTML for information disclosure, error messages or failed authentication text.
@@ -1116,7 +1108,7 @@ This is the general-purpose output analysis phase. At this point you can run rul
 ; Note : In order to access the Response Body phase data, you must have SecResponseBodyAccess set to On
 
 == Phase Logging ==
-This phase is run just before logging takes place. The rules placed into this phase can only affect how the logging is performed. This phase can be used to inspect the error messages logged by Apache. You cannot deny/block connections in this phase as it is too late. This phase also allows for inspection of other response headers that weren't available during phase:3 or phase:4. Note that you must be careful not to inherit a disruptive action into a rule in this phase as this is a configuration error in ModSecurity 2.5.0 and later versions
+This phase is run just before logging takes place. The rules placed into this phase can only affect how the logging is performed. You cannot deny/block connections in this phase as it is too late.
 
 = Variables =
 The following variables are supported in ModSecurity 3.x: