Streaming support for request processing


This feature is available in NetScaler release 10.5.e.

The NetScaler App Firewall now uses request side streaming, which results in a significant performance boost. Instead of buffering the entire request before processing it, the App Firewall now looks at the incoming data, field by field, to inspect the input of each field for any configured security check violation (SQL, XSS, Field Consistency, Field Formats, etc.). As soon as the processing of the data for a field is completed, it is forwarded to the backend while the evaluation continues for the remaining fields. This significantly improves the processing time specially when handling large posts where the forms have large number of fields.

Although the streaming process is transparent to the users, minor configuration adjustments are required due to the following changes:

RegEx Pattern Match: RegEx pattern match is now restricted to 4K for contiguous character string match.

Field Name Match: App Firewall learning engine can only distinguish the first 128 bytes of the name for learning. If a form has multiple fields with names that have identical string match for the first 128 bytes, the learning engine may not be able to distinguish between them. Similarly, the deployed relaxation rule might inadvertently relax all such fields.

Removing white spaces, percent decoding, unicode decoding, and charset conversion which is done during canonicalization is carried out prior to security check inspection. The 128 byte limit is applicable to the canonicalized representation of the field name in UTF-8 character format. The ASCII characters are 1 byte but the UTF-8 representation of the characters in some international languages may range from 1-4 bytes. If each character in the name takes 4 bytes when converted to UTF-8 format, only first 32 characters in the name may be distinguished by the learned rule for such a language.

Field Consistency Check: When the field Consistency check is enabled, all the forms in the session are now stored based on the “as_fid” tag inserted by the App Firewall without consideration for the “action_url.”

  • Mandatory Form tagging for Form Field consistency: When the field consistency check is enabled, the form tag must be enabled also. The Field Consistency protection might not work if form tagging is turned off.
  • Sessionless Form Field Consistency: The App Firewall no longer carries out the “GET” to “POST” conversion of forms when sessionless field consistency parameter is enabled. The form tag is required for sessionless field consistency also.
  • Tampering of as_fid: If a form is submitted after tampering as_fid, it now triggers field consistency violation even if no other field was tampered. In non-streaming requests, this was allowed because the forms could be validated using the “action_url” stored in the session.

Signatures: The signatures now have the following specifications:

  • Location: It is now a mandatory requirement that location must be specified for each pattern. All patterns in the rule MUST have a <Location> tag.

  • Fast Match: All signature rules must have a fast match pattern. If there is no fast match pattern, an attempt will be made to select one if possible. Fast match must be a literal string but some PCRE’s can be used for fast match if they contain a usable literal string.

  • Deprecated Locations: Following locations are no longer supported in signature rules.

    • HTTP_ANY

XSS/SQL Transform: Raw data is used for transformation because the SQL special characters ( single quote(‘), backslash (), and semicolon (;)), and XSS tags ((<) and(>)) are same in all languages and do not need canonicalization of data. All representations of these characters, such as HTML entity encoding, percent encoding, or ASCII are evaluated for transform operation.

The App Firewall no longer inspects both the attribute name and value for the XSS transform operation. Now only XSS attribute names are transformed when streaming is engaged.

Processing XSS Tags: As part of the streaming changes in 10.5.e build onwards, the App Firewall processing of the Cross-site Scripting tags has changed. In earlier releases, presence of either open bracket (<), or close bracket (>), or both open and close brackets (<>) was flagged as Cross-site Scripting Violation.  The behavior has changed in 10.5.e build onwards. Presence of only the open bracket character (<),  or only the close bracket character (>) is no longer considered as an attack. It is when an open bracket character (<) is followed by a close bracket character (>), the Cross-site scripting attack gets flagged. Both characters must be present in the right order (< followed by >) to trigger Cross-site scripting violation.  


Change in SQL violation log Message: As part of the streaming changes in 10.5.e build onwards, we now process the input data in blocks. RegEx pattern matching is now restricted to 4K for contiguous character string matching. With this change, the SQL violation log messages might include different information compared to the earlier builds. The keyword and special character in the input could be separated by a large number of bytes. We now keep track of the SQL keywords and special strings when processing the data, instead of buffering the entire input value. In addition to the field name, the log message now includes the SQL keyword, or the SQL special character, or both the SQL keyword and the SQL special character, as determined by the configured setting. The rest of the input is no longer included in the log message, as shown in the following example:


In 10.5, when the App Firewall detects the SQL violation, the entire input string might be included in the log message, as shown below:

SQL Keyword check failed for field text="select a name from testbed1\;\(\;\)".*<blocked>

In 11.0, we log only the field name, keyword and special character (if applicable) in the log message, as shown below:

SQL Keyword check failed for field text="select(;)" <blocked>

This change is applicable to requests that contain application/x-www-form-urlencoded, or multipart/form-data, or text/x-gwt-rpc content-types. Log messages generated during processing of JSON or XML payloads are not affected by this change.

RAW POST Body: The security check inspections are always done on RAW POST body.

Form ID: The App Firewall inserted “as_fid” tag, which is a computed hash of the form, will no longer be unique for the user session. It will now have an identical value for a specific form irrespective of the user or the session.

Charset: If a request does not have a charset, the default charset specified in the application profile is used when processing the request.


Counters with prefix “se_” and “appfwreq_” are added to track the streaming engine and the App Firewall streaming engine request counters respectively.

nsconsmg -d statswt0 -g se_err_

nsconsmg -d statswt0 -g se_tot_

nsconsmg -d statswt0 -g se_cur_

nsconsmg -d statswt0 -g appfwreq_err_

nsconsmg -d statswt0 -g appfwreq_tot_

nsconsmg -d statswt0 -g appfwreq_cur_

_err counters: indicate the rare event which should have succeeded but failed due to either memory allocation problem or some other resource crunch.

_tot counters: ever increasing counters.

_cur counters: counters indicating current values that keep changing based on usage from current transactions.


  • The App Firewall security checks should work exactly the same as before.
  • There is no set ordering for the processing of the security checks.

  • The response side processing is not affected and remains unchanged.
  • Streaming is not engaged if CVPN is used.


Calculating the Cookie length: In release 10.5.e (in a few interim enhancement builds prior to 59.13xx.e build) as well as in the 11.0 release (in builds prior to 65.x), App Firewall processing of the Cookie header was changed. In those releases, every cookie is evaluated individually, and if the length of any one cookie received in the Cookie header exceeds the configured BufferOverflowMaxCookieLength, the Buffer Overflow violation is triggered.  As a result of this change, requests that were blocked in 10.5 and earlier release builds might be allowed, because the length of the entire cookie header is not calculated for determining the cookie length. In some situations, the total cookie size forwarded to the server might be larger than the accepted value, and the server might respond with “400 Bad Request”.

Note that this change has been reverted. The behavior in the 10.5.e ->59.13xx.e and subsequent 10.5.e enhancement builds as well as in the 11.0 release 65.x and subsequent builds is now similar to that of the non-enhancement builds of release 10.5. The entire raw Cookie header is now considered when calculating the length of the cookie. Surrounding spaces and the semicolon (;) characters separating the name-value pairs are also included in determining the cookie length.

Streaming support for request processing

In this article