AskF5 Manual Chapter Using HTTP Headers

AskF5 | Manual Chapter: Using HTTP Headers
F5.com | Support | Community | Partners | Careers
Knowledge Centers Resources

|
My Support
AskF5 Home
/ Knowledge Center
/ BIG-IP WebAccelerator
/ Policy Management Guide for the BIG-IP WebAccelerator System
/ Using HTTP Headers

Applies To:
Show Versions
Manual Chapter:
Using HTTP Headers
Table of Contents
|
<<Previous Chapter
|
Next Chapter>>
5

Using HTTP Headers
Understanding how the WebAccelerator system uses HTTP headers
Configuring rules based on HTTP request headers
Configuring rules based on HTTP response headers
Using regular expressions and meta tags
Using HTTP/1.1 Cache-Control headers
Using ESI Surrogate-Control headers
Viewing X-PvInfo response headers
Understanding how the WebAccelerator system uses HTTP headers
Much of the WebAccelerator systems behavior is dependent on the parameters that it finds in HTTP request and response headers, based on the configured rules
associated with those parameters.
Although important, the presence or value of HTTP response headers do not influence as many aspects of the WebAccelerator systems behavior as the HTTP
request headers, because the WebAccelerator system receives HTTP response headers after performing certain types of processing. For example, a response
header cannot affect the UCI that the WebAccelerator system generates for the request and assigns to the response, however, an ESI Surrogate-Control response
https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

header always affects assembly. For more information, see Using ESI Surrogate-Control headers.
Before sending the response to a client, the WebAccelerator system also enters an informational X-PvInfo response header to the response to describe how it
handled the request. You cannot change these informational headers, and they do not affect processing, however, they can provide useful information for evaluating
your acceleration policies. For more information, see Viewing X-PvInfo response headers.
Servicing HTTP client requests
The process begins when the WebAccelerator system receives a new request from a client and reviews the HTTP request parameters to find the relevant
acceleration policy. Once it finds the relevant policy, the WebAccelerator system applies the associated matching rules, and sends the request to the origin web
server for content. To maintain high performance, the WebAccelerator system does not service an HTTP request unless the request meets the following conditions.
The request must include an HTTP request header that is no larger than 8192 bytes and must identify in the first line, its method, URI, and protocol.
The method for the HTTP request header must be a GET, POST, or HEAD.
The protocol for the HTTP request header must be HTTP/0.9, HTTP/1.0, or HTTP/1.1.
The HTTP post data on the request can be no larger than 32768 bytes.
If the request provides the Expect request header, the value must be 100-continue.
If the request provides the Content-Type request header, the value must be application/x-www-form-urlencoded.
The request must include a Host request header that identifies a targeted host that is mapped to an origin server at your site.
If the HTTP Host request header is missing, or the WebAccelerator system does not know its value, the WebAccelerator system responds to the requesting client with
a 400-series error message. If the request violates any of the other conditions, the WebAccelerator system redirects the request to the origin web servers for
processing.
Processing requests
When a WebAccelerator system receives an HTTP request that meets the conditions described in Servicing HTTP client requests, the WebAccelerator system
processes the request as follows:
1. The WebAccelerator system performs application matching against the request and retrieves the associated acceleration rules.
2. If the WebAccelerator system matches a proxying rule to the request, it sends the request to the origin web servers as required by the rule. Proxying rules are
described in Chapter 9, Configuring Proxying Rules.
3. If the request does not match to a proxying rule, the WebAccelerator system attempts to retrieve the appropriate compiled response from its cache.
4. If there is no compiled response in its cache, the WebAccelerator system sends the request to the origin web servers for content.
5. If it finds a compiled response in its cache, the WebAccelerator system determines whether there is an associated content invalidations rule for the compiled
response. For the conditions and mechanisms that trigger a content invalidations rule, see Chapter 11, Configuring Invalidations Rules.
6. If a content invalidations rule is triggered for the compiled response, the WebAccelerator system examines the rules effective time against the compiled
responses last refreshed time. If the compiled responses last refreshed time is before the content invalidations rules triggered time, the WebAccelerator system
sends the request to the origin web servers for content.
7. If a content invalidations rule is not triggered, or if the compiled responses last refreshed time is after the invalidations rules effective time, the WebAccelerator
system examines the compiled responses TTL value to see if the compiled response has expired. If it has expired, the WebAccelerator system sends the request
to your origin web servers.
8. If the compiled response has not expired, the WebAccelerator system services the request using the cached compiled response.
Caching responses

When the WebAccelerator system receives a response from the origin web server, it inspects the HTTP response headers, applies the acceleration rules to the
response, and sends the content to the client
To ensure the most effective performance, the WebAccelerator system does not cache a response from the origin server, or forward it to the originating requestor,
unless it meets the following conditions.
The request must not match to a do-not-cache proxying rule.
See Chapter 9, Configuring Proxying Rules for more information.
The first line of the response must identify the protocol, a response code that is an integer value, and a response text.
For example: HTTP/1.1 200 (OK)
If the Transfer-Encoding response header is used on the response, the value must be chunked.
The WebAccelerator system must consider the response content complete. The WebAccelerator system uses different methods to determine if content is
complete, based on the type of data contained within the response as follows:
HTML tags
By default, the WebAccelerator system considers a response in the form of an HTML page complete only if it contains both beginning and ending HTML tags.
Content-Length response header
If a response is anything other than an HTML page, or if you have overridden the default behavior described in the previous bullet point, the WebAccelerator system
considers content complete only if the response body size matches the value specified on the Content-Length response header.
Chunked transfer coding
If you do not use a Content-Length response header for a response, you must use chunked transfer coding. If you use chunked transfer coding, theWebAccelerator
system does not consider content complete until it receives the final zero-sized chunk. For information about chunked transfer coding, see section 3.6 in the
HTTP/1.1 specification http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6
The body of a response must not exceed the value of the maxResponseDataSize parameter in the WebAccelerator systems configuration file. By default, this value
is 2MB.
If the WebAccelerator system receives a response from the origin server that does not conform to these conditions, the WebAccelerator system will not cache the
response and will redirect the response to the original requesting client.
Configuring rules based on HTTP request headers
The HTTP request data type parameters, which are specified within the matching rules and acceleration rules of an acceleration policy, dictate how the
WebAccelerator system processes an HTTP request. For example, a rule can specify that if an HTTP request matches a certain HTTP request data type parameter,
either the WebAccelerator system sends the request to the origin web server, or that the WebAccelerator system substitutes a certain value when providing a
response to the client.
In most cases, the default values for the pre-defined acceleration policies are sufficient, but you can fine-tune the WebAccelerator systems behavior by creating a
user-defined acceleration policy and modifying the HTTP request data type parameters. When you specify or modify an HTTP request data type parameter, you
designate the following information.
Identity of the parameter, which can include one or more of the following:
Parameter type
Parameter name
Parameter location within the HTTP request

The value or required state of the parameter for the WebAccelerator system to find a match. This can include one or more of the following:
Parameter is present in the HTTP request and matches the specified value provided in the form of a regular expression.
Parameter is present in the HTTP request and does not match the specified value provided in the form of a regular expression.
Parameter is present in the HTTP request, but has no value (is an empty string).
Parameter is not present in the HTTP request.
The action that the WebAccelerator system takes when the state or value of the parameter is met. This includes:
Whether the WebAccelerator system performs an action on a match or a no match
What action that the WebAccelerator system performs, which is dictated by the rules in the associated acceleration policy
For example, if you specify in a rule that dictates that the WebAccelerator system performs a certain action when a request does not match a configured parameter,
then the rule triggers the action if the parameter in the request is a different value than you specified, or if the value is empty (null). The WebAccelerator system does
not perform the specified action if the parameter does not appear in the request.
Specifying HTTP request data type parameters in a rule
You cannot configure rules based on all HTTP request data types parameters; you can only specify the parameters that the WebAccelerator system uses when
processing HTTP requests. Table 5.1 outlines the HTTP data type parameters that you can configure specific rules.
Matching Variation Assembly Proxying Invalidations
Parameters Rules Rules Rules Rules Rules
Protocol x x x x
Host x x x x
Path x x
Extension x x
Method x x x x
Query parameter x x x x x
Unnamed query parameter x x x x x
Path segment x x x x x
Cookie x x x x
User Agent x x x x
Referrer x x x x
Header x x x x
Client IP x x x x
Table 5.1 HTTP request data type parameters

Note: Lifetime rules and responses cached rules, described in Chapter 10, Configuring Lifetime Rules, and Chapter 12, Configuring Responses Cached Rules, do not
use HTTP data type parameters.
The HTTP data type parameters that the WebAccelerator system uses when processing HTTP requests, are defined as follows.
Note: To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.
Protocol
A rule that uses the HTTP request data type parameter, protocol, is based on whether the request uses the HTTP or HTTPS protocol. For example, the following URL
uses the HTTP protocol:
http://www.siterequest.com/apps/srch.jsp?value=computers

The following URL uses the HTTPS protocol:
https://www.siterequest.com/apps/srch.jsp?value=computers
Host
A rule that uses the HTTP request data type parameter, host, is based on the value provided for the HTTP Host request header field. This header field describes the
DNS name that the HTTP request is using. For example, in the following URL:

the host equates to the following:
HOST: www.siterequest.com
Path
A rule that uses the HTTP request data type parameter, path, is based on the path portion of the URI. The path is defined as everything in the URL after the host and
up to the end of the URL, or up to the question mark, whichever comes first. For example, the following URL paths:
http://www.siterequest.com/apps/magic.jsp

equate to the following paths, respectively:
/apps/srch.jsp
/apps/magic.jsp
Extension
A rule that uses the HTTP request data type parameter, extension, is based on the value that follows the far-right period, in the far-right segment key of the URL path.
Note: Segment keys, the text following the semicolon and preceding the question mark in the third URL, are described in Path segment.
For example, in the following URLs, gif, jpg, and jsp are all extensions:
http://www.siterequest.com/images/up.gif
http://www.siterequest.com/images/down.jpg
http://www.siterequest.com/apps/psrch.jsp;sID=AAyB23?src=magic
Method
A rule that uses the HTTP request data type parameter, method, is based on whether the request used the GET or POST method.
Query parameter

A rule that uses the HTTP request data type parameter, query parameter, is based on a particular query parameter that you identify by name, and for which you
provide a value to match against. The value is usually literal and must appear on the query parameter in the request, or a regular expression that matches the
requests query parameter value. The query parameter can be in a request that uses GET or POST methods.
You can also create a rule that matches the identified query parameter when it is provided with an empty value, or when it is absent from the request. For example, in
the following URL the action query parameter provides an empty value:
http://www.siterequest.com/apps/srch.jsp?action=&src=magic
Unnamed query parameter
An unnamed query parameter is a query parameter that has no equal sign. That is, only the query parameter value is provided in the URL of the request. For
example, the following URL includes two unnamed query parameters that have the value of dog and cat:
http://www.siterequest.com/apps/srch.jsp?dog&cat&src=magic
A rule that uses the parameter, unnamed query, specifies the ordinal of the parameter, instead of a parameter name. The ordinal is the position of the unnamed query
parameter in the query parameter portion of the URL. You count ordinals from left to right, starting with 1. In the previous URL, dog is ordinal 1, and cat is ordinal 2.
You can create a rule that matches the identified (unnamed) query parameter when it is provided with an empty value, or when it is absent from the request. For
example, in the following URL, ordinal 1 provides an empty value.
http://www.siterequest.com/apps/srch.jsp?&cat&src=magic
In the following URL, ordinal 3 is absent (dog is in ordinal 1 and src is in ordinal 2).
http://www.siterequest.com/apps/srch.jsp?dog&src=magic.
Path segment
The HTTP request data type parameter, path segment, is used to identify one of the following values provided:
Segment key
Segment parameter
Segment keys
A segment is the portion of a URI path that is delimited by a forward slash (/). For example, in the path: /apps/search/full/complex.jsp, apps, search, full, and
complex.jsp all represent path segments. Further, each of these values are also the segment key, or the name of the segment.
Segment parameters
A segment parameter is the value in a URL path that appears after the segment key. Segment parameters are delimited by semicolons. For example, magic, shop,
and act are all segment parameters for their respective path segments in the following path:
/apps/search/full;magic/complex.jsp;shop;act
To specify segment parameters, you must also identify:
Segment ordinals
Segment parameter ordinals
Segment ordinals
To specify a segment for a rule, you must provide an ordinal that identifies the location of the segment in the path:
/apps/search/full;magic/complex.jsp;shop;act
You must also indicate in the rule, which way you are counting ordinals in the path: from the left or the right (you always count starting at 1). For the example shown,
/full;magic, the ordinals for this path are as show in Table 5.2.

Ordinal Numbering Selection
3 Numbering Left-to-Right in the Full

Path
2 Numbering Right-to-Left in the Full

Path
Table 5.2 Segment ordinals example

Segment parameter ordinals
When you specify a segments ordinal for a rule, you must also identify the ordinal of the element within the segment on which the rule is based. When you count
segment parameter ordinals, you always left-to-right in the path, and the segment key is always ordinal 0. For example, in the following segment:
/complex.jsp;shop;act
the segment key is complex.jsp and its ordinal is 0. Segment parameters shop and act have ordinals 1 and 2 respectively.
Cookie
A rule that uses the HTTP request data type parameter, cookie, is based on a particular cookie that you identify by name, and for which you provide a value to match
against. Usually the value is literal and must appear on the cookie in the request, or a regular expression that must match the requests cookie.
The names of the cookies that you identify must match the names that appear on the cookie HTTP request headers and are the same names you used to set the
cookies, using the HTTP SET-COOKIE response headers.
You can also create a rule that matches when the identified cookie is provided with an empty string or when it is absent from the request. For example, in the
following string, the following REPEAT cookie is empty:
COOKIE: REPEAT=
In the following string, the USER cookie is present and the REPEAT cookie is absent:
COOKIE: USER=334A5E4.
User agent
A rule that uses the HTTP request data type parameter, user agent, is based on the value provided for the HTTP USER_AGENT in the request header. This header
identifies the browser that sent the request. For example, the following USER_AGENT request header indicates that the requesting browser is IE 5.01 running on
Windows NT 5.0:
USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

You do not typically base rules on the USER_AGENT request header, unless your site behaves differently depending on the browser in use.
Referrer
A rule that uses the HTTP request data type parameter, referrer, is based on the value provided for the HTTP REFERER in the request header. (Note the misspelling
of REFERER. This spelling is defined for this request header in all versions of the HTTP specification.)
This header provides the URL location that referred the client to the page that the client is requesting. That is, REFERER provides the URL that contains the hyperlink
that the user clicked to request the page. For example:
REFERER: http://www.siterequest.com/
You do not typically base rules on the REFERER request header, unless you want your sites behavior to be dependent on the specific referrer. For example, one
implementation would be for sites that provide different branding for their pages based on the users web portal or search engine.
Header
A rule that uses the HTTP request data type parameter, header, is based on a particular header that you identify by name, and for which you provide a value to match
against. You can use an HTTP request data type header parameter to create rules based on any request header, other than one of the recognized HTTP request
data types that are listed in Table 5.1.
The HTTP request data type header parameter you use can be standard HTTP request header fields such as AUTHORIZATION, CACHE-CONTROL, and FROM.
They can also be user or acceleration defined headers in the form of a structured parameter.
Following are examples of HTTP request data type parameters:
Accept: text/html, image/*
Accept-Encoding: gzip
Accept-Language: en-us
CSP-Gadget-Realm-User-Pref: NM=5,PD=true,R=3326
The last header in the example depicts a structured parameter.
The format of a structured parameter in a request is similar to that used for a cookie, with a header name that you choose, followed by a series of name=value pairs
separated by commas. The header name is not case-sensitive and in this structure, the semicolons (;) are special characters. The parser ignores anything after a
semicolon until it reaches the subsequent comma. For example, following are valid header structured parameters:
CSP-Global-Gadget-Pref: AT=0
CSP-Gadget-Realm-User-Pref: NM=5,PD=true,R=3326
CSP-User-Pref: E2KU=chi,E2KD=ops%u002esiterequest%u002enet,E2KM=chi
CSP-Gateway-Specific-Config: PT-User-Name=chi,PT-User-ID=212,PT-Class-ID=43
Standards: type=SOAP;SOAP-ENV:mustUnderstand="1",version=1.2
In the last line, the parser ignores SOAP-ENV:mustUnderstand="1", because it follows a semicolon. Since version=1.2 follows the command, the parser reads it as a
name=value pair. If you have meta data that you want to include in the header, but want the WebAccelerator system to ignore, put it after a semicolon.
If you specify a header as a structured parameter when creating a rule, the WebAccelerator system parses it into name=value pairs when it examines the request. If
you do not specify it as a structured parameter, the WebAccelerator system processes it like a normal header, and treats everything after the colon (:) as the value.
To define a header as a structured parameter when you are creating or editing a rule, you specify the name using the following syntax:
headername:parmname
Where:
headername
Is the name of the header.
parmname
Is the name of the parameter with the value that you want to affect the rule.
Using the CSP-Global-Gadget-Pref header as an example, if you want the WebAccelerator system to evaluate the value for AT to determine if a configured rule
should apply, specify the name of the header parameter as follows:
CSP-Global-Gadget-Pref:AT

If you want the WebAccelerator system to evaluate the entire string without assigning meaning to name=value pairs, specify the name of the header parameter as
follows:
CSP-Global-Gadget-Pref
You can create a rule that matches when the identified header is provided with an empty value, or when it is absent from the request.
In the following example, the WebAccelerator system considers Standards:release, empty and considers Standards:SOAP-ENV absent, because it is ignored:
Standards: type=SOAP;SOAP-ENV:mustUnderstand="1",release=,version=1.2
Client IP
When a rule is based on the HTTP request data type parameter, client IP , the WebAccelerator system looks at the IP address of the client making the request. The
IP address, however, may not always be the address of the client that originated the request.
For example, if the client goes through a proxy server, the IP address is the IP address of the proxy server, rather than the client IP address that originated the
request. If several clients use a specific proxy server, they all appear to come from the same IP address.
Configuring rules based on HTTP response headers
Response headers influence processing that occurs only after the response has exited the Rewrite Engine. Response headers have no effect on application
matching, variation, or invalidations rules. The WebAccelerator system evaluates response headers that affect caching after it compiles, but before it caches, the
content. Once the WebAccelerator system begins the compilation and assembly process, it then examines existing response headers that affect assembly.
After the WebAccelerator system receives a response from the origin web server, it performs the following processes:
Classifies the response
Applies associated acceleration rules
Assembles the response
You can configure assembly, proxying, lifetime, or responses cached rules to affect the WebAccelerator systems behavior based on response headers. It is, however,
important to note that if you configure proxying rules for this purpose, you can use them only in terms of how the proxying rules affect the WebAccelerator systems
ability to cache the response, because the WebAccelerator system has already sent the request to the origin web servers when it reviews the response headers.
Classifying responses
After the WebAccelerator system receives a response from the origin server, and before it performs application matching, it classifies the response based on the
object types that are defined on the Object Types screen. The WebAccelerator system bases this classification on the first item it finds, in the following order:
The file extension in the file name field of the responses Content-Disposition header
The file extension in the extension field of the responses Content-Disposition header
The responses Content-Type header, unless it is an ambiguous MIME type
The requests path extension
For example, if the extension in the file name field of the responses Content-Disposition header is empty, the WebAccelerator system looks at the responses Content-
Disposition headers file extension in the extension field. If that has an extension, the WebAccelerator system attempts to match it to a defined object type. If there is
no match, the WebAccelerator system assigns an object type of other and uses the settings for other. The WebAccelerator system only examines at the information
in the Content-Type header if there is no extension in the file name or extension fields of the Content-Disposition header.
If the WebAccelerator system finds a match to an object type, it classifies the response with that object type, group, and category, and uses the associated settings
for compression. The object type and group under which the response is classified is also included in the X-PvInfo response header. For more information, see
Viewing X-PvInfo response headers.

Important: The compression settings defined for the object override the assembly rules compression settings for the responses matched node. You define object
types and groups from the Object Types screen and the WebAccelerator system stores these settings in its globalfragments.xml file. For specific information about
how to configure object types, see the Changing Default Settings chapter in the Configuration Guide for the BIG-IP WebAcceleratorTM System.
Once the WebAccelerator system classifies the response by object type, it generates a content type, by appending the object type to the group to which the object
type belongs as follows: group.objectType. The WebAccelerator system then performs application matching to the response (the first matching process was for the
request), using the new content type. In many cases, this content type is the same as the content type for the request, and the WebAccelerator system matches the
response to the same node as the request. The WebAccelerator system also matches the response to the same node as the request, if the Content Type parameter
is not specified in a matching rule. After the WebAccelerator system matches the response to a node, it applies the associated acceleration policy rules to the
response.
Unlike the HTTP request data types, you do not base a matching rule directly on the value of an HTTP response data type. Instead, you base the rule on the content
type parameter that the WebAccelerator system generates, by specifying the regular expression that you want a request or responses content type to match, or not
to match.
Rewriting and compiling responses
After clarifying the response, the WebAccelerator system uses the Rewrite Engine to run any associated response rewrite scripts, defined by one of the following:
The responses object type.
The assembly rules for the node to which the response matched.
In most cases, an associated rewrite script is defined in the assembly rules, not the object type, However, if a rewrite script is defined for the object type, the
WebAccelerator system uses the object types rewrite script and ignores the rewrite script defined in the acceleration policys assembly rules.
After the WebAccelerator system runs the rewrite script, it compiles the response, and determines if it can cache it, by looking for a responses cached rule for the
node that matches the response. If the response is cache-able, the WebAccelerator system caches a copy of the response.
Assembling responses
Once the WebAccelerator system has applied associated response rewrite scripts, compiled, and cached the response, it assembles the response using the following
information:
The assembly rules specified for the node that matches the response.
The Enable Compression setting (configured from the Object Types screen) for the object type under which the response was classified. The options for this setting
are:
Policy Controlled
The WebAccelerator system uses the compression settings configured in the acceleration policys assembly rules.
None
The WebAccelerator system never compresses the response. This option overrides the compression setting in the acceleration policys assembly rules. Select this
option only if you want the WebAccelerator system to ignore assembly rules for the specified object type.
In Symmetric Deployment only
The WebAccelerator system compresses the response only when it sends it to another WebAccelerator system, but never compresses the response when sending a
response to a browser client. This option overrides the compression setting in the acceleration policys assembly rules. Select this option only if you have a symmetric
deployment and want the WebAccelerator system to compress this object type when it is sent between a central and remote WebAccelerator system.
If the response includes an ESI Surrogate-Control header, the WebAccelerator system performs ESI processing as part of the assembly and applies any associated

lifetime rules and parameter substitutions configured for the node, and then sends the response to the client. For more information, see Using ESI Surrogate-Control
headers.
Using regular expressions and meta tags
When the WebAccelerator system performs pattern matching based on regular expressions, it assumes all regular expressions are in the form of ^expression$, even
if you do not explicitly set the beginning of line (^) and end of line ($) indicators. For substring searches, you enter *expression.* as a regular expression.
The string that the WebAccelerator system matches is dependent on the HTTP data type for which you are providing the regular expression. Before the
WebAccelerator system attempts to match information in an HTTP request to the HTTP request data type parameters, it translates any escaped characters (such as
%2F or %2E) back to their regular form, such as (/ or .,).
Supported regular expression strings
The HTTP data types supported by the WebAccelerator system are defined in the Table 5.3.
HTTP data type String definition
host The value set for the HTTP Host request header.
For example, the WebAccelerator system matches the
following HTTP Host request header:
HOST: www.siterequest.com
To the following string:

www.siterequest.com
path The value set for the path portion of the URI.
For example, for the following URI:
http://www.siterequest.com/apps/search.jsp?value=computer
The WebAccelerator system matches to the following string:

/apps/search
extension The value set for the extension portion of the URI.
For example, for the following URI:
http://www.siterequest.com/apps/search.jsp?value=computer

jsp
query parameter The value set for the identified query parameter.
For example, the WebAccelerator system matches the
following value set for the action query parameter:
http://www.siterequest.com?action=display&PDA
To the following string:

display

unnamed query The value set for the identified query parameter.
parameter For example, if the value set for the unnamed query
parameter in ordinal 2 is as follows:
http://www.siterequest.com?action=display&PDA

PDA
path segment The name of the segment key, or the value set for the
segment parameter, depending on what you have identified
for the match.
For example, if you identify the path segment in ordinal 1 for
the full path (counted from left-to-right) and parameter ordinal
0, that means that in the following URL you have identified
the segment key:
http://www.siterequest.com/apps;AAY34/search.jsp?value=computer

apps
If you specify parameter ordinal 1, the WebAccelerator system

matches to:
AAY34
cookie The value set for the identified cookie.

For example, for the following cookie:
COOKIE: SESSIONID=TN2MM1QQL

TN2MM1QQL
user agent The value set for the HTTP USER_AGENT request header.
For example, for the following user agent:
USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
referrer The value set for the HTTP REFERER request header.
For example, for the following referrer:
REFERER: http://www.siterequest.com?action=display

http://www.siterequest.com?action=display

header The value set for the identified header.

For example, for the following header:
Accept-Encoding: gzip

gzip
Table 5.3 HTTP data types and string definitions

Supported meta characters
The WebAccelerator system uses the meta characters defined in the following table for pattern matching. As long as you use the escape character, you can use one
of these meta characters as a literal value for fields that expect a regular expression.
Pattern Description
. Matches any single character.
^ Matches the beginning of the line in a regular

expression.
Note that the WebAccelerator system assumes
that the beginning and end of line meta
characters exist for every regular expression it
sees.
$ Matches the end of the line.

Note that the WebAccelerator system assumes
that the beginning and end of line meta
characters exist for every regular expression it
sees.
* Matches zero or more of the patterns that

precede it.
For example, the expression G.*P.* matches to
the following:
GrandPlan
GreenPeace
GParse
GP
You can begin a pattern with the * character,

which is the same as using: .*
For example, the WebAccelerator system
considers the following two expressions identical.
*Plan
.*Plan
+ Matches one or more of the patterns that precede

it.
For example, the expression G.+P.* matches to
the following:
GrandPlan
GreenPeace
Do not begin a pattern with the + character. For

example, do not use +Plan
Instead, use the following:
.+Plan
? Matches none, or one of the patterns that

precede it.
For example, the expression G.?P.* matches to
the following:
GParse
GP
Do not begin a pattern with the ? character. For

example, do not use ?Plan
Instead, use the following:
.?Plan
[...] Matches a set of characters. You can list the

characters in the set using a string made of the
characters to match.
For example, the expression C[AHR] matches to
the following:
CAT
CHARISMA
CRY
You can also provide a range of characters using

a dash. For example, the expression AA[0-9]+
matches the following:
AA269812209
AA2
However, it does not match AAB2.

To match any alphanumeric character, both
upper- and lower-case, use the following
expression:
[a-zA-Z0-9]
[^...] Matches any character not in the set. Just as with

the character, [...], you can specify the individual
characters, or a range of characters by using a
dash (-).
For example, the expression C[^AHR].* matches
the following:
CLEAR
CORY
CURRENT
But does not match:

CAT
CHARISMA
CRY
(...) Matches the regular expression contained inside

the parenthesis, as a group.
For example, the expression AA(12)+CV matches
the following:
AA12CV
AA121212CV
exp1 Matches either exp1 or exp2, where exp1 and

exp2 exp2 are regular expressions.
For example, the expression AA([de]12|[zy]13)CV
matches the following:
AAd12CV
AAe12CV

AAz12CV
AAy13CV
Table 5.4 Patterns and symbols to use for pattern matching

Using HTTP/1.1 Cache-Control headers
The HTTP Cache-Control version 1.1 header specification identifies headers that you can use to control web entities, such as the WebAccelerator system. (For
additional information, see sections 13 and 14 of the HTTP/1.1 specification at http://www.w3.org/Protocols/rfc2616/rfc2616.html.)
HTTP Cache-Control headers can appear on requests sent by clients and on responses sent by the origin web servers. The HTTP Cache-Control general-header
field specifies directives for all caching mechanisms along the request/response chain, and is used to prevent caching behavior from adversely interfering with the
request or the response. Some directives can appear only in response headers, and some can appear only in request headers, and certain directives can appear in
either type of header. The HTTP Cache-Control general-header field directives typically override any default caching algorithms.
Specifying cache response directives
If you disable the Ignore no-cache HTTP headers in the response option in the HTTP Lifetime Header section of the lifetime rule screen, the WebAccelerator system
uses the cache response directives that it receives from the origin web server. The origin web servers cache response directives are organized in two groups:
no-cache
These are directives that prompt the WebAccelerator system to not cache a response. You can enable the lifetime rules Ignore no-cache HTTP headers in the
request option to prompt the WebAccelerator system to ignore the HTTP Cache-Control headers no-cache directives. Doing so may result in a noticeable drop in
the traffic sent to the origin web server, depending on how many users send no-cache directives in their requests.
max-age
These are directives that the WebAccelerator system uses to help determine the TTL value for compiled response.
no-cache
The HTTP Cache-Control headers no-cache directives prompt the WebAccelerator system to send a request to the origin web servers, and also dictate whether the
WebAccelerator system should cache the response. The no-cache directives are described in Table 5.5.
Directive Description
Pragma: no-cache If the pragma general-header field specifies no-cache, the

WebAccelerator system does not cache the response.
For information about this header field, see section 14.32 of
the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32
Cache-Control: no-cache If Cache-Control general-header field specifies no-cache,

the WebAccelerator system does not cache the response.
For information about this header field, see section 14.9.1
of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

Cache-Control: no-store If Cache-Control general-header field specifies no-store, the
For information about this header field, see section 14.9.2
of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2
Cache-Control: private If Cache-Control general-header field specifies private, the

For more information about this directive, see Section
14.9.1 of the HTTP 1.1 specification:
http://www.w3.org/Protocols/rfc2616/rfc2616-
sec14.html#sec14.9.1
Table 5.5 HTTP Cache-Control headers no-cache directives
max-age
For HTTP Cache-Control headers, the WebAccelerator system uses the value for the directives defined in Table 5.6, in order of priority, to determine the TTL values
for compiled responses. For example, if the TTL values for the s-maxage and the max-age directives are different, the WebAccelerator system uses the TTL value
for the s-maxage directive.
The max-age directives are described in Table 5.6.
Priority Directive Description
1 Cache-Control: s-maxage The WebAccelerator system bases the TTL on

the current time, plus the value specified for the
Cache-Control headers s-maxage directive.
Values for this directive are expressed in
seconds.
For information about this directive, see section
2 Cache-Control: max-age The WebAccelerator system bases the TTL on

the current time, plus the value specified for the
Cache-Control headers max-age directive.
Values for this directive are expressed in
seconds.
For information about this directive, see section
3 Expires The WebAccelerator system uses the TTL

provided for Cache-Control headers entity-
header field. Values for this field are expressed in
Coordinated Universal Time (UTC time).
To avoid potential issues, it is important to ensure
that that the WebAccelerator system is properly
synchronized with the origin web server,
therefore, F5 Networks highly recommends that
you configure a Network Time Protocol (NTP)
server.
For information about configuring NTP on the
BIG-IP system, refer to the TMOS Management
Guide for BIG-IP Systems, which is available on
the Technical Support web site,
https://support.f5.com.
For information about this header field, see
section 14.21 of the HTTP 1.1 specification:
sec14.html#sec14.21
4 Last-Modified The WebAccelerator system bases this TTL using

the following formula:
TTL = curr_time + ( curr_time - last_mod_ time ) *
last_mod_factor
Where:
curr_time is the time that the response is received
by the WebAccelerator system
last_mod_ time is the time specified by this
directive
last_mod_factor is a percentage value used to
weight the TTL you set it with a lifetime rule.
For information about this header field, see
section 14.29 of the HTTP 1.1 specification:
sec14.html#sec14.29
Table 5.6 HTTP Cache-Control headers max age directives

Important: The HTTP Cache-Control headers max-age directive is not the same as the the value of the Maximum Age setting for the lifetime rules WebAccelerator
system Cache Settings. You use the HTTP Cache-Control headers max-age directive to define a TTL for content. The lifetime rules Maximum Age setting is a
boundary condition beyond which, for example, the HTTP Cache-Control headers max-age directive cannot surpass. For more information about lifetime rule
parameters, see Configuring a lifetime rule example.
Freshness calculation considerations
In general, freshness calculations for HTTP headers are based on the date or age value received in the HTTP response, as defined in section 13.2.3 of the HTTP
version 1.1 specification: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.3
However, the WebAccelerator system assumes that the values for date and age are 0, so it bases all age calculations on the time that it receives a response from the
origin web server.
The extent to which this matters depends on the combination of:
The time delay between when a response leaves the origin web server and it is received by the WebAccelerator system.
The difference between the UTC time set for the origin web servers and the WebAccelerator systems UTC time.
In most cases, these issues are negligible, however, to ensure that the WebAccelerator system maintains proper synchronization with the origin web server, F5
Networks highly recommends that you configure a Network Time Protocol (NTP) server. For information about configuring the NTP server, see the Configuration and
Maintenance Tasks chapter in the Configuration Guide for the BIG-IP WebAcceleratorTM System.
Specifying cache request directives
If the client sends an HTTP request header that prevents the WebAccelerator system from serving the content from its cache, the WebAccelerator system sends the
request to the origin web server. This event prompts the WebAccelerator system to refresh the corresponding content that it has cached, even if that content has not
yet expired.
When using HTTP Cache-Control headers, the WebAccelerator system uses the cache request directives described in Table 5.7.
Header Description
Pragma: no-cache If the pragma general-header field includes the no-cache

directive, the WebAccelerator system sends the request to
the origin web servers.
For information about this field, see section 14.32 of the
HTTP/1.1 specification:
Cache-Control: no-cache If Cache-Control specifies no-cache, then the

WebAccelerator system sends the request to the origin
web servers.
For information about this field, see section 14.9 of the
HTTP/1.1 specification:
Cache-Control: no-store If Cache-Control specifies no-store, the WebAccelerator

system sends the request to the origin web server.
Cache-Control: max-age If the max-age value for the Cache-Control header is less
than the current age of the cached content, the
WebAccelerator sends the request to the origin web
server.
Cache-Control: min-fresh The WebAccelerator system sends the request to the origin
web server if the following is true:
curr_time + min_fresh_time > content_TTL
Where:
curr_time is the time that the request is received by the
WebAccelerator system.
min_fresh_time is the time specified by this directive.
content_TTL is the time to live value set for the compiled
response that corresponds to the request.
Table 5.7 Cache request directives

If you want the WebAccelerator system to ignore HTTP request no-cache headers and to serve responses from cache, in accordance with the configured lifetime
rules, you can enable the lifetime rules Ignore no-cache HTTP headers in the request option.
Using ESI Surrogate-Control headers
Edge Side Includes (ESI) is a simple markup language that supports web surrogates, such as the WebAccelerator system, and is used to define web page
components for dynamic assembly and delivery of web applications. For those sites that use ESI for page assembly, you can use ESI Surrogate-Control headers to
manage the WebAccelerator systems behavior.
When the WebAccelerator system receives an HTTP request that it cannot service from cache, it adds an ESI Surrogate-Capabilities header to the HTTP request and
then sends it to the origin server for content. The Surrogate-Capabilities header specifies wa as the device token used by the WebAccelerator system, and identifies
the WebAccelerator system as an ESI 1.0 compliant device, as follows:
Surrogate-Capabilities: wa=ESI/1.0
Note: See Using surrogate targeting, for information about specifying a device token.
The response that the origin web erver returns must contain an ESI Surrogate-Control response header if there is any ESI markup in the response. The ESI
specification that defines the Surrogate-Control response header is available at http://www.esi.org/architecture_spec_1-0.html site.
Supported Surrogate-Control directives
Origin web servers use Surrogate-Control response header control directives to dictate how web surrogates manage content processing and caching for response

entities.
The WebAccelerator system supports the following Surrogate-Control response header control directives:
Content
No-store
Max-age
If the ESI Surrogate-Control header contains more than one of these directives, they must be separated by a comma (,). The WebAccelerator system ignores any
unsupported directives defined in the ESI Surrogate-Control response header.
Content directive
The WebAccelerator system requires that the origin server include an ESI Surrogate-Control response headers content directive (always specified as a name=value
pair) in an HTTP response, if it contains ESI markup. At a minimum, a content directive header must have the following value:
Surrogate-Control: content="ESI/1.0"
If the response does not include an ESI Surrogate-Control response header, the WebAccelerator system ignores any ESI markup that appears in the response.
no-store directive
The Surrogate-Control response headers no-store directive is always specified as the string no-store. For example: Surrogate-Control: content="ESI/1.0",no-store
If the response includes an ESI Surrogate-Control header with the no-store directive, the WebAccelerator system does not cache the response.
max-age directive
Expressed in seconds, the Surrogate-Control response headers max-age directive specifies how long to cache content. For example, max-age=3600 indicates that
the content should be cached for 1 hour. The WebAccelerator system uses this value as the compiled responses TTL value.
You can also define a stand-in period, expressed with a + operator. For example, max-age=1800+600 indicates that the content should be cached for 30 minutes with
a 10 minute stand-in interval. For more information, see Configuring a lifetime rule example.
Important: The ESI Surrogate-Control headers max-age directive is not the same as the Maximum Age setting for the lifetime rules WebAccelerator system Cache
Settings. You use the ESI Surrogate-Control headers max-age directive to define an actual TTL for content. The lifetime rules Maximum Age setting are a boundary
condition beyond which, for example, the ESI Surrogate-Control headers max-age directive cannot pass. For more information about lifetime rule parameters, see
Configuring a lifetime rule example.
Overriding HTTP Cache-Control headers
If ESI Surrogate-Control headers appear in an HTTP response from the origin server, the WebAccelerator system ignores any existing HTTP 1.1 Cache-Control
headers that appear in the same response.
For example, if a response includes a Surrogate-Control response headers max-age directive and an HTTP 1.1 no-cache or no-store header, the WebAccelerator
system caches the response. The HTTP 1.1 Cache-Control headers supported by the WebAccelerator system are described in Configuring the WebAccelerator
systems cache setting options.
The exception to this rule is that you can use a lifetime rule to direct the WebAccelerator system to ignore the Surrogate-Control response ESI headers max-age
directive. For information about configuring lifetime rules, see Using lifetime rules.
Using surrogate targeting
Surrogate targeting is an ESI mechanism that allows you to control a specific surrogate device. This mechanism is required, because a site can contain multiple web
surrogates. You can use surrogate targeting to identify header information that is meant for the WebAccelerator system, by adding a parameter to the Surrogate-
Control directive. This allows an origin server to specify one directive value for the WebAccelerator system, for example, and a different value for all other surrogates.

The origin server appends the parameter to the directive using a semicolon (;). A comma (,) separates the parameter from any other directives that follow. For
example:
Surrogate-Control: max-age=3600+600;wa,max-age=3600
This example is parsed as follows:
max-age=3600+600;wa
Resulting in a max-age of 30 minutes with a 10 minute stand-in interval for the WebAccelerator system.
max-age=3600
Resulting in a max-age of 30 minutes for all other devices.
The device token in this example is wa. The wa device token was defined to the origin web servers in the Surrogate-Capability request header that the
WebAccelerator system added to the request before it sent the request to the origin web servers.
The WebAccelerator system always uses a device token of wa in the Surrogate-Capability header.
Viewing X-PvInfo response headers
Before sending a response to a client, the WebAccelerator system inserts an X-PvInfo response header that includes specific codes. The X-PvInfo response header
is for informational purposes only and provides a way for you to assess the effectiveness of your acceleration policy rules.
The object type and group under which the response is classified is also included in the X-PvInfo response header. The object type is preceded by OT and the group
is preceded by OG, as in the following example:
OT/msword,OG/documents
You define object types and groups from the Object Types screen and the WebAccelerator system stores the information in its global fragment file,
config/wa/globalfragment.xml. The object type for the response indicates if the WebAccelerator system overrode the rewrite or compression settings in the assembly
rule for the node specified by the A code. (See also, A code.)
Note: For more information about how the WebAccelerator system classifies objects, see Classifying responses. For information about adding or modifying object
type settings and specifying groups, see the Changing Default Settings chapter in the Configuration Guide for the BIG-IP WebAcceleratorTM System.
You can view X-PvInfo response headers by:
Performing a packet capture of the page.
Using an HTTP viewer utility like HttpWatch, HTTP Analyzer, or Live Headers.
Using the WebAccelerator systems hit logs. For more information about the hit logs, see Chapter 13, Specifying Log Formats for Hit Logs.
S code
The S code is the first field of the X-PvInfo response header. This field code indicates whether the object in the HTTP response was served from cache, or was sent
to the original web server. The S codes are defined in Table 5.8.
Code Definition Description
SO Response was served from an The WebAccelerator system was unable

unknown source. to determine if a response was cached or
sent to the origin web server for content.
S10101 Response was served from This indicates that the response was

Smart Cache (memory). served from memory.
S10102 Response was served from This indicates that the response was
Smart Cache (disk). served from disk.
S10201 Request was sent to the origin The WebAccelerator system caches the
web server, because it was for response from the origin web server for
new content. future requests, before responding to the
request. The WebAccelerator system will
respond to future request for this content,
from cache.
S10202 Response was sent to the origin When cached content exceeds the
web server, because the cached maximum age setting, the
content had expired. WebAccelerator system sends the next
request to the origin web server for new
content. After revalidating the content, the
WebAccelerator system serves future
requests from cache, until the maximum
age is once again exceeded.
S10203 Response was sent to the origin When the WebAccelerator system
web server, in accordance with matches a request to a node with an
an acceleration policy. acceleration rule set to always proxy, the
WebAccelerator system will send that
request to the origin web server, rather
than serving it from cache.
S10204 Response was sent to the origin The WebAccelerator system does not
web server, because of specific currently support some vendor-specific
HTTP or web service methods. HTTP methods (such as OPTIONS) and
some web services methods (such as
SOAP). The WebAccelerator system
sends requests containing those methods
to the origin web server for content. In
addition, if the WebAccelerator system
matches a request to a node with a no-
cache directive, the WebAccelerator

system will send the request to the origin
server and will not save the response to
cache.
S10205 Response was sent to the origin Cache invalidation can be conducted
web server because the cached through manual invalidations, through
content was invalidated. direct XML messaging over HTTPS on
port 8443, or prompted by an acceleration
rule parameter. After the WebAccelerator
system invalidates cache and retrieves
new content from the origin web server, it
stores the response and serves future
requests from cache.
S10206 Response was sent to the origin If the WebAccelerator system matches a
web server because the request over an NTLM-authenticated
response required connection to a node with an acceleration
authentication from the origin rule configured that does not allow
web server. cached NTLM-authenticated content, it
sends that request to the origin server for
content, and it does not cache the
response.
S10301 Response was sent to the origin Large multimedia objects often cannot be
web server, because the optimized. Such content is typically
response contained large composed of large files that are already
multimedia objects. compressed and too large to cache. The
WebAccelerator system can be
configured to recognize these objects and
to send them directly to the origin web
server for content.
S10413 Request and response bypassed When a response exceeds the value
the WebAccelerator system. specified in the WebAccelerator system's
pvsystem.conf file for the
maxResponseDataSize parameter, the
WebAccelerator system does not match
and apply an acceleration policy to the
response.
S10414 Request and response bypassed When the WebAccelerator system's

the WebAccelerator system. license is expired it does not match and
apply acceleration policies to requests or
responses.
S11101 Response was served from Hot This indicates that the response was
Cache. served from memory without requiring
specific assembly processing by the
WebAccelerator system. This is the most
efficient and fastest response method.
Table 5.8 S code definitions
A code
The A code is the fourth field of the X-PvInfo response header, and identifies to which node on the Policy Tree the WebAccelerator system matched the request. This
helps you determine which acceleration rules the WebAccelerator system applied to the request.
To view a nodes ID in an acceleration policy
1. On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2. On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying the existing acceleration policies.
3. Click the name of the acceleration policy for which you want to view the nodes ID.
The Policy Editor screen opens.
4. On the Policy Tree, place your cursor on a node.
The ID appears in parentheses below the cursor.
C code
The C code is the second field of the X-PvInfo response header, and it indicates the acceleration policy that the WebAccelerator system applied to the request. The C
code is also part of the path where cached objects are stored on disk, and also identifies the specific application used. For example, if you have two applications
defined in an acceleration policy, the WebAccelerator system saves cached content for the first application under parent directory 1, and cached content for the
second application under parent directory 2.
P code
The P code is the third field of the X-PvInfo response header. This field is always populated with an L for live production acceleration policy.
R code
The R code is the fifth field of the X-PvInfo response header, and it identifies the application match of a response, to an acceleration policy. The WebAccelerator
system can perform response-based application matching against MIME types in a response, or by matching attachment file name extensions. Request-based
application matching against extensions (defined in the globalfragment.xml file) in the URL path is not considered a response application match; however, a request
application match appears in the A field.
In addition, you can configure an assembly rule to specify custom rewrites that redirect one application match to another application match in an acceleration policy.
This is most often used to handle exceptions to a general application match rule. For more information about configuring assembly rules, see Chapter 8, Configuring
Assembly Rules.
A 0 (zero) R code in the X-PvInfo response header indicates that the WebAccelerator system did not use response-based application matching.
G code
The G code is the sixth field of the X-PvInfo response header. The G code, when converted from hexadecimal to decimal, identifies where cached objects are stored
on disk. The value of the G code is called the Application Sign number. The Application Sign changes when you make edits to an acceleration policy (generally to
variation rules) that result in a substantial change in the way the WebAccelerator system manages a request, making it difficult to revalidate existing cached objects.
Moving Application Sign changes to a new cache subdirectory is similar to wiping the disk cache, except that disk space is not freed and must be reclaimed using the
hds_prune process.
U code
The U code is the seventh field of the X-PvInfo response header and is a hexadecimal cache ID number. The U code identifies where cached objects are stored on
disk.

Table of Contents
|
<<Previous Chapter
|
Next Chapter>>
Was this resource helpful in solving your issue? Additional Comments (optional)
Yes - this resource was helpful Type your comment here (1000
No - this resource was not helpful character limit)...
I dont know yet
NOTE: Please do not provide personal information.
Incorrect answer. Please try again:

Please
enter the words to the right: Please enter the
numbers you hear: Reload
Audio
Image
Help
Enter Captcha Here Submit

ABOUT F5 EDUCATION F5 SITES SUPPORT CONNECT WITH US

TASKS
Contact F5 Training F5.com
Create Service

Careers Certification Community

Events Free Online Partners Request
Training Contact Support

Leave feedback
[+]
Copyright 2016 by F5 Networks, Inc. | Policies | Trademarks

AskF5 Manual Chapter Using HTTP Headers

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AskF5 Manual Chapter Using HTTP Headers

Uploaded by

Copyright:

Available Formats

AskF5 | Manual Chapter: Using HTTP Headers

F5.com | Support | Community | Partners | Careers

Knowledge Centers Resources

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

Parameters Rules Rules Rules Rules Rules

Table 5.1 HTTP request data type parameters

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

3 Numbering Left-to-Right in the Full

2 Numbering Right-to-Left in the Full

Table 5.2 Segment ordinals example

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

HTTP data type String definition

To the following string:

The WebAccelerator system matches to the following string:

The WebAccelerator system matches to the following string:

To the following string:

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

The WebAccelerator system matches to the following string:

The WebAccelerator system matches to the following string:

If you specify parameter ordinal 1, the WebAccelerator system

cookie The value set for the identified cookie.

The WebAccelerator system matches to the following string:

The WebAccelerator system matches to the following string:

The WebAccelerator system matches to the following string:

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

header The value set for the identified header.

The WebAccelerator system matches to the following string:

Table 5.3 HTTP data types and string definitions

. Matches any single character.

^ Matches the beginning of the line in a regular

$ Matches the end of the line.

* Matches zero or more of the patterns that

You can begin a pattern with the * character,

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

+ Matches one or more of the patterns that precede

Do not begin a pattern with the + character. For

? Matches none, or one of the patterns that

Do not begin a pattern with the ? character. For

[...] Matches a set of characters. You can list the

You can also provide a range of characters using

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

However, it does not match AAB2.

[^...] Matches any character not in the set. Just as with

But does not match:

(...) Matches the regular expression contained inside

exp1 Matches either exp1 or exp2, where exp1 and

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

Table 5.4 Patterns and symbols to use for pattern matching

Pragma: no-cache If the pragma general-header field specifies no-cache, the

Cache-Control: no-cache If Cache-Control general-header field specifies no-cache,

https://support.f5.com/kb/en-us/products/wa/manuals/product/wa_pmg_1000/wa_httpdata.html[08/12/2016 05:31:46 p.m.]

Cache-Control: private If Cache-Control general-header field specifies private, the

Table 5.5 HTTP Cache-Control headers no-cache directives

Priority Directive Description

1 Cache-Control: s-maxage The WebAccelerator system bases the TTL on

2 Cache-Control: max-age The WebAccelerator system bases the TTL on

3 Expires The WebAccelerator system uses the TTL

4 Last-Modified The WebAccelerator system bases this TTL using

Table 5.6 HTTP Cache-Control headers max age directives