Specifications

Chapter 6: Administering Virtual Clusters
82 Equalizer Installation and Administration Guide
Enabling the Once Only Flag for Persistent Connections
Since HTTP 1.1, web browsers and servers have been able to negotiate persistent connections over
which multiple HTTP transactions could take place, by specifying a keep-alive option in the request
header. This is useful when several TCP connections are required in order to satisfy a single client
request.
For example, before HTTP 1.1, if a browser wished to retrieve the file index.html from the server
www.coyotepoint.com, the browser would take the following actions:
1. Browser opens TCP connection to
www.coyotepoint.com.
2. Browser sends request to server “GET /index.html”.
3. Server responds with the content of the page (a bunch of HTML).
4. Server closes connection.
5. Browser determines that there are objects (images) in the HTML document that need to be
retrieved, so the browser repeats Steps 1 to 4 for each of the objects.
As you can imagine, there is a lot of overhead associated with opening and closing the TCP
connections for each image. The way HTTP 1.1 optimizes this is by allowing multiple objects
(pages, images, etc) to be fetched and returned across one TCP socket connection. The client
requests that the server keep the connection open by adding the request header Connection: keep-
alive to the request.
If the server agrees, the server will also include Connection: keep-alive in its response headers, and
the client is able to send the next request over the persistent HTTP connection without the bother of
opening additional connections. This is how Equalizer behaves.
For a Layer 7 cluster, Equalizer evaluates (and possibly changes) both the request and response
headers that flow between the client and server (the request and response bodies are not examined).
Match rules are applied to each client header, cookies may be inserted, and headers may be
rewritten. When a client includes keep-alive in its headers, there is a fair amount of work required
by the Equalizer to determine when the next set of request headers is ready to be parsed (evaluated),
since there may be quite a lot of data going across the connection between sets of headers. To
reduce this workload, the once only flag instructs the Equalizer to evaluate (and potentially modify)
only the first set of headers in a connection.
So, in our example above, only the headers in the request for the index.html file are evaluated; the
subsequent requests to obtain the images are not evaluated.
To summarize, enabling once only has the following effects:
• Match rules are only evaluated for the first request in a keep-alive connection.
• Header modifications such as insertion of persistence cookies and header rewriting will only
be performed on the first response in a keep-alive connection.
An example of the latter behavior concerns the insertion of headers related to HTTPS processing.
For an HTTPS cluster, Equalizer offloads SSL processing from the servers in the cluster; that is, it
processes the HTTPS request and forwards it in HTTP to the server. When it does this, it inserts
special headers into the request to indicate that the request was received by Equalizer in HTTPS and
processed into HTTP (see “HTTPS Header Insertion” on page 85). If once only is set, these special
headers are only inserted into the first request in a connection; the remainder of the requests in the
connection are still processed, but no headers are inserted. Therefore, if you want to be able to parse