K40243113: Overview of the HTTP profile Non-Diagnostic Original Publication Date: Dec 20, 2018 Update Date: Jun 8, 2021 Topic The BIG-IP system provides the HTTP profile as an option for processing HTTP traffic. The HTTP profile allows the virtual server to operate in full Layer 7 (L7) inspection mode and use features such as the following: Full HTTP iRules logic OneConnect functionality (including OneConnect transformations) L7 persistence (cookie, hash, universal, and iRules) HTTP pipelining Virtual Server Authentication Cookie Encryption Request / Response Chunking Description A virtual server with an associated HTTP profile processes connections using the BIG-IP system's full proxy architecture for the purpose of making requests on behalf of clients. In this mode, the BIG-IP system processes the three-way TCP handshake and initial data packet on the client-side connection before initiating the TCP handshake on the server-side connection; the client's data packet triggers the BIG-IP system to initiate the server-side connection. Important: HTTP profiles are incompatible with encrypted pass-through traffic, such as SSL and require a Client SSL profile to decrypt the traffic for L7 HTTP inspection. If the virtual server processing the encrypted traffic is configured with an HTTP profile and no Client SSL profile, the connection fails. The HTTP profile provides settings to configure full L7 functionality for your virtual sever traffic. You can use the default profile settings or configure custom profile settings when you create a profile. The following table contains the settings and definitions for the HTTP profile. Settings Setting Default Description Name None Specifies the name of the profile. The proxy mode setting determines whether the virtual server operates in reverse, explicit, or transparent mode. The proxy mode offers different HTTP enforcement options for the profile and allows you to configure the system to act as a gateway in the case of explicit proxy mode. The following proxy mode options are available: Reverse - Sets enforcement options that are suitable for many deployments and enables the BIG-IP system to manage responses from multiple servers. Explicit - Changes the enforcement options for the profile and enables the Proxy Mode Reverse BIG-IP system to process HTTP proxy requests and function as a gateway. By configuring browser traffic to use the proxy, you can control whether to allow or deny a requested connection, based on configured policies. The Explicit Proxy Mode requires a DNS resolver, specified in the Explicit Proxy area of the screen. Transparent - Changes the enforcement options for the profile and enables the BIG-IP system to forward invalid HTTP traffic to a specified server, instead of dropping the connection. By configuring an HTTP profile to forward invalid HTTP traffic, you can manage various atypical service provider scenarios, such as HTTP traffic from non-browser clients that function as web browsers. Parent Profile http Indicates the parent profile from which this profile inherits settings. Indicates the realm that is sent to the client when basic HTTP authentication to Basic Auth None the virtual server fails. From the server perspective, the realm allows a Realm protected resource to be partitioned into a set of protection spaces. The BIG-IP system can redirect a request to a fallback host when all members of the targeted pool are unavailable, or if a selected pool member is unavailable (for example, the pool member is disabled, marked as down, or has exceeded Fallback Host None its connection limit). When one or more pool members are unavailable, the BIG- IP system can redirect the HTTP request to the specified fallback host, with the HTTP reply Status Code 302 Found. Indicates the HTTP error codes from server responses that should trigger a Fallback on redirection to the fallback host. If you are specifying more than one code, None Error Codes separate the codes with a blank space, such as 500 501 502. You can also specify a range of error codes, as in this example: 505-515. Indicates the name of an HTTP request header that the BIG-IP system removes from the client request. Only one header can be removed per pool, unless you Request are using LTM Policies or iRules. None Header Erase Note: The Header Erase option works only on headers in HTTP requests from clients to servers. The Request Header Insert is a string that the system inserts as a header in an Request HTTP request. If the header exists already, the system does not replace it. For None Header Insert multiple header insertions, both LTM Policies and iRules support inserting multiple headers into a request Response Can be any headers within an HTTP response that the system is to allow. If you Headers None are specifying more than one header, separate the headers with a blank space. Allowed For example, if you enter the string Content-Type Set-Cookie Location, the system then allows the headers Content-Type, Set-Cookie, and Location. BIG-IP 15.0.0 and later The behavior in each mode depends on whether the client sends chunked or unchunked requests and replaces the previous options of Preserve and Selective. The options are defined in Response Chunking. Note: The Sustain option is the default, starting with the release of BIG-IP 15.0.0, replacing the earlier release versions' use of Preserve. BIG-IP prior to 15.0.0 Preserve - The chunked transfer encoding method modifies the body of an HTTP message and transfers it as a series of chunks. The Request Chunking setting indicates how the BIG-IP system handles HTTP content that uses chunked encoding in the client request. The behavior in each mode depends on whether the client sends chunked or unchunked requests. For content that is chunked: Preserve: The BIG-IP system processes the chunked content and sends the request to the server unchanged. Selective: The BIG-IP system unchunks the HTTP content, processes the Sustain data, re-adds the chunk headers, and then sends the chunked request or Request response to the server. Note that for chunked content, this mode is the Chunking same as the Rechunk mode. Unchunk: For chunked content, specifies that the system unchunks the response, processes the HTTP content, and passes the response on as unchunked. The Keep-Alive value for the Connection header is not supported, so the system sets the value of the header to close. If the response is unchunked, the system processes the HTTP content and passes the response on untouched. Rechunk: The BIG-IP system unchunks the HTTP content, processes the data, re-adds the chunk headers, and then sends the chunked request or response to the server. For content that is unchunked: Preserve: The BIG-IP system processes the HTTP content and sends the request to the server unchanged. Selective: The BIG-IP system processes the HTTP content and sends the request to the server unchanged. Rechunk: The BIG-IP system processes the HTTP content, adds the transfer encoding and chunk headers to the response, and then sends the chunked request to the server. BIG-IP 15.0.0 and later Specifies that the system preserves request or response chunking unless there is a command to modify the body. If the request or response is chunked, unchunk the HTTP content, process the data, and re-add chunking headers on egress. Chunk extensions will be lost. When the response is chunked, it can be rechunked on egress to the client. Note: The Sustain option is the default, starting with the release of BIG-IP 15.0.0, replacing the earlier release versions' use of Selective. Unchunk: For chunked content, specifies that the system unchunks the response, processes the HTTP content, and passes the response on as unchunked. The Keep-Alive value for the Connection header is not supported, so the system sets the value of the header to close. If the response is unchunked, the system processes the HTTP content and passes the response on untouched. Rechunk: Specifies that the system unchunks the request or response, processes the HTTP content, re-adds the chunk trailer headers, and then passes on the request or response as chunked. Any chunk extensions are lost. If the request or response is unchunked, the system adds transfer encoding and chunking headers on egress. Sustain: Specifies that the system preserves request or response chunking unless there is a command to modify the body. If the request or response is chunked, unchunk the HTTP content, process the data, and re-add chunking headers on egress. Chunk extensions will be lost. When the response is chunked, it can be rechunked on egress to the client. BIG-IP prior to 15.0.0 Selective -The chunked transfer encoding modifies the body of an HTTP Sustain message and transfers it as a series of chunks. The Response Chunking Response setting specifies how the BIG-IP system handles HTTP content that is chunked Chunking by the server. The behavior in each mode depends on whether the server sends chunked or unchunked responses. For content that is chunked: Preserve: The BIG-IP system processes the chunked content and sends the response to the client unchanged. Selective: The BIG-IP system unchunks the HTTP content, processes the data, re-adds the chunk headers, and then sends the chunked request or response to the client. Note that for chunked content, this mode is the same as the Rechunk mode. Unchunk: The BIG-IP system removes the HTTP transfer encoding headers, removes the chunk headers, processes the HTTP content, and then sends the unchunked response to the client. The system closes the connection once it sends all data Rechunk: The BIG-IP system unchunks the HTTP content, processes the data, re-adds the chunk headers, and then sends the chunked request or response to the client.