Add improved control of caching to all this, and we begin to see where 1.1 flexes its muscles. HTTP/1.1 allows developers to decide which parts of a page a proxy server should cache. You may want everything cached except a cookie. Or you may want to cache additional items with the Vary: Accept header. It allows you to say, "Cache this document, but if the Accept header in the client request is different, then please ask me again so I can give you a different answer." Say a client requests an image/gif from /foo via the proxy to the server. The server sends back the image/gif - with a Vary: Accept header. If a second client requests /foo, but asks for image/jpeg, the proxy must forward the request to the original server again to get the correct image format.
-
|
C
|
request /foo
---->
Accept: image/gif
|
P
|
request /foo
---->
Accept: image/gif
|
S
|
|
C
|
response
<----
Content-Type: image/gif
|
P
|
response
<----
Vary: Accept
Content-Type: image/gif
|
S
|
|
C2
|
request /foo
---->
Accept: image/gif
|
P
|
|
S
|
|
C2
|
response
<----
Content-Type: image/gif
|
P
|
|
S
|
|
C3
|
request /foo
---->
Accept: image/jpeg
|
P
|
request /foo
---->
Accept: image/jpeg
|
S
|
C3
|
response
<----
Content-Type: image/jpeg
|
P
|
response
<----
Vary: Accept
Content-Type: image/jpeg
|
S
|
C, C2, and C3 are different clients.
P is the proxy.
S is the server.
|
If the proxy already has /foo cached and the Accept header is the same, the request doesn't need to go to the server again. In the table above, the proxy has two versions of /foo cached - one of type image/gif, and one of type image/jpeg. It serves the correct one according to the Accept: header sent by the client.
next page»
