Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: A - Requirements for Cache Behavior
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


A

Requirements for Cache Behavior


Servicing HTTP client requests

To maintain high performance, the WebAccelerator system does not service an HTTP request unless it meet 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 HOST header is missing, or its value is unknown to the WebAccelerator, 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 your origin 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 caching rules. Application matching is described in Understanding acceleration policies , located in Chapter 2.
  2. If the WebAccelerator system matches a proxying rule to the request, it sends the request to the origin servers as required by the rule. Proxying rules are described in Chapter 9 .
  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 servers for content.
  5. If it finds a compiled response in its cache, the WebAccelerator system determines if there is an associated content invalidation rule for the compiled response. For the conditions and mechanisms that trigger a content invalidation rule, see Chapter 11 .
  6. If a content invalidation rule is triggered for the compiled response, the WebAccelerator system examines the rule's effective time against the compiled response's last refreshed time. If the compiled response's last refreshed time is before the content invalidation rule's triggered time, the WebAccelerator system sends the request to the origin servers for content.
  7. If there a content invalidation rule is not triggered, or if the compiled response's last refreshed time is after the invalidation rule's effective time, the WebAccelerator system examines the compiled response's TTL value to see if the compiled response has expired. If it has expired, the WebAccelerator system sends the request to your origin servers.
  8. If the compiled response has not expired, the WebAccelerator system services the request using the cached compiled response.

Caching responses

To maintain high 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, 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 response must be complete, as described in Determining the completeness of response content , located in Chapter 13. The WebAccelerator system decides what constitutes a complete response depending on the type of the response, as follows:
    • For HTML pages.
      The response must contain both the beginning and ending HTML tag. You can disable this behavior by editing the responses cached rule and clearing the Cache only if the document contains matching begin and end tags check box.
    • For all other types of pages.
      The response body size must match the value specified on the Content-Length response header. If you do not use the Content-Length header for the response, you must use chunked transfer-coding. If you use chunked transfer-coding, theWebAccelerator system does not consider the response complete until it receives the final zero-sized chunk. For more information, see section 3.6 in the HTTP/1.1 specification for information on chunked encoding: 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 system's 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.




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)