HTTP/1.1 cache control
HTTP/1.1 uses the Cache-Control
header field as its basic caching control mechanism. The Cache-Control
header can be used in both HTTP requests and responses, however, we consider only HTTP responses here. Setting the Cache-Control
header field to no-cache
in a HTTP response prevents the response from being cached by a HTTP/1.1 user agent.
Some HTTP/1.1 Cache-Control
settings are directed to user agents that maintain caches for more that one user, such as a proxy server. Proxy servers are used to achieve several goals; one is to provide caching of responses for a group of users. A local network, such as that found in a university department, can be configured to send all HTTP requests to a proxy server. The proxy server forwards requests to the destination web server and passes back the responses to the originating client. Proxy servers can cache responses and thus reduce requests sent outside the local network. Setting the Cache-Control
header field to public
allows a user agent to make the cached response available to any request. Setting the Cache-Control
header field to private
allows a user agent to make the cached response available only to the client who made the initial request.
Setting the Cache-Control
header to no-store
prevents a user agent from storing the response in nonvolatile storage, such as a hard disk. This prevents sensitive information from being inadvertently saved beyond the life of a browser session. HTTP/1.1 defines several other Cache-Control
header fields not described here.
The HTTP/1.1 standard is relatively new, and there are several user agents that aren't HTTP/1.1-aware or -compliant. While HTTP/1.1 provides better cache control directives, it is wise to include header fields that are understood by HTTP/1.0 browsers, proxy servers, and other user agents.
HTTP and TCP/IP
Each time a HTTP request is sent, a TCP/IP connection is made. When a browser makes a request, the following network activity results:
-
The browser initiates a TCP/IP connection to the web server on the host and port identified in the URL of the request.
-
The host sends back a TCP acknowledgment to indicate a virtual circuit has successfully been established.
-
The browser sends the HTTP request in full to the server using the established connection.
-
The server acknowledges the receipt of the request and starts to generate a response. The browser waits for the response and times out if the response doesn't arrive within a preset time limit.
-
The server sends the HTTP response message to the browser.
-
The browser acknowledges the receipt of the complete HTTP response.
-
The server disconnects the virtual circuit.
Each HTTP request-response sequence is a completely separate network connection: each request message sent by a web browser-or any other HTTP user agent-is totally independent of any other request. Every request message a web server receives has its own separate response. This independence of requests is what makes the HTTP protocol stateless.