Applies To:

Show Versions Show Versions

Manual Chapter: HTTP Profiles
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Introduction to http profiles

BIG-IP Local Traffic Manager offers several features that you can use to intelligently control your application layer traffic. Examples of these features are the insertion of headers into HTTP requests and the compression of HTTP server responses.

These features are available through various configuration profiles. A profile is a group of settings, with values, that correspond to HTTP traffic. A profile defines the way that you want the BIG-IP system to manage HTTP traffic.

To manage HTTP traffic, you can use any of these profile types:

  • HTTP (Hypertext Transfer Protocol)
  • HTTP Compression
  • Web Acceleration

In addition to these profiles, Local Traffic Manager includes other features to help you manage your application traffic, such as health monitors for checking the health of HTTP and HTTPS services, and iRulesfor querying or manipulating header or content data. For more information, see the remainder of this guide.

HTTP profile type

You can configure an HTTP profile to ensure that HTTP traffic management suits your specific needs. You can configure the profile settings when you create a profile, or after profile creation by modifying the profile’s settings.

For these profile settings, you can specify values where none exist, or modify any default values to suit your needs.

You can also use the default HTTP profile, named http, as is, if you do not want to create a custom HTTP profile.

The http profile is considered a default profile because it does not inherit setting values from a parent profile.

Parent profile

Every profile that you create is derived from a parent profile. You can use the default http profile as the parent profile, or you can use another HTTP profile that you have already created.

Fallback host

Another feature that you can configure within an HTTP profile is HTTP redirection. HTTP redirection allows you to redirect HTTP traffic to another protocol identifier, host name, port number, or URI path.

Redirection to a fallback host occurs if all members of the targeted pool are unavailable, or if a selected pool member is unavailable. (The term unavailable refers to a member being disabled, marked as down, or having exceeded its connection limit.) When one or more pool members are unavailable, Local Traffic Manager can redirect the HTTP request to the fallback host, with the HTTP reply Status Code 302 Found.

Although HTTP redirection often occurs when the system generates an LB_FAILED iRule event, redirection can also occur without the occurrence of this event, such as when:

  • The selected node sends an RST after a TCP 3WHS has completed, but before the node has sent at least a full response header.
  • Local Traffic Manager finds the selected node to be unreachable while receiving the body portion of a request or a pipelined request.

When configuring Local Traffic Manager to redirect HTTP traffic to a fallback host, you can specify an IP address or a fully-qualified domain name (FQDN). The value that you specify becomes the value of the Location header that the server sends in the response. For example, you can specify a redirection as http://redirector.siterequest.com.

Fallback error codes

In addition to redirecting traffic when a target server becomes unavailable, you can also specify the HTTP error codes from server responses that should trigger a redirection to the fallback host. Typical error codes to specify are 500, 501, and 502.

Headers in HTTP requests

You can insert headers into HTTP requests. The HTTP header being inserted can include a client IP address. Including a client IP address in an HTTP header is useful when a connection goes through a secure network address translation (SNAT) and you need to preserve the original client IP address.

The format of the header insertion that you specify is generally a quoted string. Alternatively, however, you can insert a Tools Command Language (Tcl) expression into a header that dynamically resolves to the preferred value. When you assign the configured HTTP profile to a virtual server, Local Traffic Manager then inserts the header specified in the profile into any HTTP request that the BIG-IP system sends to a pool or pool member.

Note: In addition to inserting a string such as a client IP address into an HTTP request, you can configure Local Traffic Manager to insert SSL-related headers into HTTP requests. Examples are: client certificates, cipher specifications, and client session IDs. To insert these types of headers, you must create an iRule.

Content erasure from HTTP headers

You can configure a profile to erase the contents of a header from an HTTP request that is being sent from a client to a server. With this feature, you can erase header content from HTTP requests before forwarding the requests over the network. Such headers might contain sensitive information, such as user IDs or telephone numbers, that must be erased before the information is forwarded.

When you use this setting, Local Traffic Manager erases the contents of the specified header and replaces that content with blank spaces. The header itself is retained.

Note: This feature does not apply to HTTP responses being sent from a server to a client.

The client header with the contents to be erased must be specified as a quoted string.

Headers in an HTTP response

You can specify any headers within an HTTP response that you want the BIG-IP system to allow. If you are specifying more than one header, separate the headers with a blank space. For example, if you type the string Content-Type Set-Cookie Location, the BIG-IP system then allows the headers Content-Type, Set-Cookie, and Location.

Response chunking

Sometimes, you might want to inspect and/or modify HTTP application data, such as compressing the content of an HTTP response. Such inspections or modifications require that the response be unchunked, that is, not in chunked encoding. Using the Response Chunking feature, Local Traffic Manager can unchunk a chunked response before performing an action on that response.

Possible chunking behaviors of Local Traffic Manager

The BIG-IP system takes specific action on a response depending on whether the response is chunked or unchunked.

Action Original response is chunked Original response is unchunked
Unchunk Local Traffic Manager unchunks the response and processes the HTTP content, and passes the response on as unchunked. The connection closes when all data is sent to the client as indicated by the Connection: Close header. Local Traffic Manager processes the HTTP content and passes the response on untouched.
Rechunk Local Traffic Manager unchunks the response, processes the HTTP content, re-adds the chunk trailer headers, and then passes the response on as chunked. Any chunk extensions are lost. Local Traffic Manager adds transfer encoding and chunking headers on egress.
Selective Same as Rechunk. Local Traffic Manager processes the HTTP content and then passes the response on untouched.
Preserve Local Traffic Manager leaves the response chunked, processes the HTTP content, and passes the response on untouched. Note that if HTTP compression is enabled, Local Traffic Manager does not compress the response. Local Traffic Manager processes the HTTP content and then passes the response on untouched.

OneConnect transformations

You can enable or disable part of the OneConnect feature, for HTTP/1.0 connections only. When this setting is enabled and a OneConnect profile is assigned to the virtual server, the setting performs Connection header transformations, for the purpose of keeping a client connection open. More specifically:

  1. A client sends an HTTP/1.0 request.
  2. The server sends a response, which initially includes a Connection: Close header.
  3. Local Traffic Manager transforms the Connection: Close header to Connection: Keep-Alive.
  4. Through use of the OneConnect profile, the server-side connection detaches, goes into the pool of available server-side connections used for servicing other requests, and eventually closes. This process is hidden from the client.
  5. The client-side connection remains open, operating under the assumption that the server-side connection is still open and therefore able to accept additional requests from that client.
Note: For this feature to take effect, you must also configure a OneConnect profile, which enables connection pooling.

Rewrites of HTTP redirections

Sometimes, a client request is redirected from the HTTPS protocol to the HTTP protocol, which is a non-secure channel. If you want to ensure that the request remains on a secure channel, you can cause the redirection to be rewritten so that it is redirected back to the HTTPS protocol.

To enable Local Traffic Manager to rewrite HTTP redirections, you use the Rewrite Redirections setting to specify the way that you want the system to handle URIs during the rewrite.

Note that the rewriting of any redirection takes place only in the HTTP Location header of the redirection response, and not in any content of the redirection.

Possible values

When configuring Local Traffic Manager to rewrite HTTP redirections, you specify one of these values:

None
The system does not rewrite any redirections. This is the default value.
All
The system rewrites the URI in all HTTP redirect responses. In this case, the system rewrites those URIs as if they matched the originally-requested URIs.
Matching
The system rewrites the URI in any HTTP redirect responses that match the request URI (minus an optional trailing slash).
Nodes
The system rewrites the hidden node IP address to a virtual server address, and rewrites the port number. You choose this value when the virtual server is not configured with a Client SSL profile (that is, when the virtual server is configured to process plain HTTP traffic only).
Note: For values All, Matching, and Nodes, the system always hides the node IP address. Also, the system hides the node IP address independently of the protocol rewrite, with no regard to the protocol in the original redirection.

Examples of rewriting HTTP redirections with the system listening on port 443

This table shows examples of how redirections of client requests are transformed when the BIG-IP system is listening on port 443, and the Rewrite Redirections setting is enabled.

Original Redirection Rewrite of Redirection
http://www.myweb.com/myapp/ https://www.myweb.com/myapp/
http://www.myweb.com:8080/myapp/ https://www.myweb.com/myapp/

Examples of rewriting HTTP redirections with the system listening on port 4443

This table shows examples of how redirections of client requests are transformed when the BIG-IP system is listening on port 443, and the Rewrite Redirections setting is enabled.

Original Redirection Rewrite of Redirection
http://www.myweb.com/myapp/ https://www.myweb.com:4443/myapp/
http://www.myweb.com:8080/myapp/ https://www.myweb.com:4443/myapp/

Cookie encryption and decryption

You can use the Configuration utility to encrypt one or more cookies that the BIG-IP system sends to a client system. When the client sends the encrypted cookie back to the BIG-IP system, the system decrypts the cookie.

Maximum header size

This setting specifies the maximum size in bytes that the BIG-IP system allows for all HTTP request headers combined, including the request line. If the combined headers length in bytes in a client request exceeds this value, the system stops parsing the headers and resets the TCP connection. The default value is 32,768 bytes.

Support for pipelining

Normally, a client cannot initiate a request until the previous request has received a response. HTTP/1.1 pipelining allows clients to initiate multiple requests even when prior requests have not received a response. Note, however, that each initiated request is still processed sequentially; that is, a request in the queue is not processed until the previous request has received a response.

By enabling support for pipelining on the BIG-IP system, you remove the need to enable pipelining on the destination server itself. By default, this feature is enabled.

XForwarded for header

When using connection pooling, which allows clients to make use of existing server-side connections, you can insert the XForwarded For header into a request. When you configure Local Traffic Manager to insert this header, the target server can identify the request as coming from a client other than the client that initiated the connection. The default setting is Disabled.

Maximum columns for linear white space

You can specify the maximum number of columns allowed for a header that is inserted into an HTTP request.

Linear white space separators

You can specify the separator that Local Traffic Manager should use between HTTP headers when a header exceeds the maximum width specified by the LWS Maximum Columns feature.

Maximum number of requests

You can specify the maximum number of requests that the system allows for a single Keep-Alive connection. When the specified limit is reached, the final response contains a Connection: close header, which is followed by the closing of the connection. The default setting is 0, which in this case means that the system allows an infinite number of requests per Keep-Alive connection.

Proxy Via headers

You can configure the BIG-IP system to remove, preserve, or append Via headers in HTTP client requests, HTTP server responses, or both.

Overview: Using Via headers

Via headers provide useful information about intermediate routers that can be used in network analysis and troubleshooting.

About using Via headers in requests and responses

The Via header, configured in an HTTP profile, provides information about each intermediate router that forwards a message. Intermediate routers between a client and an origin web server use the Via header to indicate intermediate protocols and recipients. This information can be used for the following tasks:

  • Identifying the intermediate routers that forward messages.
  • Identifying the protocols for intermediate routers.
About identifying intermediate routers with a Via header

The Via header, configured in an HTTP profile, concatenates information for each router in a response or request, separated by commas. For example, the following Via header includes two routers, with each router comprising the required protocol and address:

Via: 1.1 wa.www.siterequest1.com, 1.1 wa.www.siterequest2.com

When a client initiates a request with a Via header to an origin web server, the origin web server returns a response with a Via header often following a similar path. For example, a Via header router sequence for the request would be 1, 2, 3, and the router sequence for the client's response would be 3, 2, 1.

The inverse is true when an origin web server initiates a response with a Via header to a client. For example, a Via header router sequence for a response would be 1, 2, 3, and the router sequence for the client's request would be 3, 2, 1.

About identifying protocols for intermediate routers with a Via header

You can identify specific protocols and versions of protocols for intermediate routers by using a Via header, configured in an HTTP profile. When a client sends a request to an origin web server, the header information is concatenated for each intermediate router, including the protocol type (if different from HTTP) and version.

The Via header includes both required and optional protocol information about each router, as follows:

  • The HTTP protocol name is optional; however, other protocol names are required.

  • The protocol version of the message is required, which for HTTP is 1.0, 1.1, and so on.

  • The host name is required. For privacy purposes, however, an alias can replace the actual host name.

  • The port number associated with the host name is optional. When the port number is omitted, the default port applies.

  • A comment describing the router is optional, and includes whatever string you specify in the Send Proxy Via Header Host Name field, by selecting Append in the list for Send Proxy Via Header In Request or Send Proxy Via Header In Response.

    Note: If you prefer to replace the host name with another string, instead of appending a string to the Via header, you must use an iRule or the command line.

Because the Via header includes the protocol name and version, applications are able to acquire this information for the various intermediate routers and use it, as necessary.

Via Header settings

This table describes controls and strings for Via Header settings in an HTTP profile.

Control Default Description
Send Proxy Via Header In Request Remove Specifies whether to Remove, Preserve, or Append Via headers included in a client request to an origin web server.
  • Remove. The BIG-IP system deletes the Via header from the client request.
  • Preserve. The BIG-IP system includes the Via header in the client request to the origin web server.
  • Append. The BIG-IP system appends the string specified in the Send Proxy Via Header In Host Name field to the Via header in the client request to the origin web server.
Send Proxy Via Header In Response Remove Specifies whether to Remove, Preserve, or Append Via headers included in an origin web server response to a client.
  • Remove. The BIG-IP system deletes the Via header from the origin web server response.
  • Preserve. The BIG-IP system includes the Via header in the origin web server response to the client.
  • Append. The BIG-IP system appends the string specified in the Send Proxy Via Header In Host Name field to the Via header in the origin web server response to the client.
Send Proxy Via Header Host Name None Specifies a string to append as a comment when sending a Via header in a request to an origin web server or in a response to a client.
Note: If you prefer to replace the host name with another string, instead of appending a string to the Via header, you must use an iRule or the command line.

Protocol security

You can specify that the system inspect HTTP traffic for security vulnerabilities when you configure a security profile in Protocol Security Manager. This option is available only when you are licensed for that module.

Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




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:

Additional Comments (optional)