Http 304 & Cache-Control: no-cache

Question

I see the following answer from some calls to the web server:

Initial Call:

HTTP/1.1 200 OK Date: Mon, 16 Jan 2012 05:46:49 GMT X-Powered-By: Servlet/2.5 JSP/2.1 Content-Type: text/plain Content-Length: 78 Content-Encoding: gzip Etag: "pv2052dae8634d971149a927231e3ceddf" Cache-Control: no-cache X-PvInfo: [S10202.C6191.A6057.RA6008.G182D.U3FAE8760].[OT/plaintext.OG/documents] Vary: Accept-Encoding Set-Cookie: JSESSIONID=l9pLPT5J1tpgK19Fq2qlT0F15ryByWDLgVLz16ffWPm4qQp6nzzx!-518520380; path=/; HttpOnly DST=rd319o00000000000000000000ffffac16018bo8200; path=/ Connection: close 

Subsequent calls:

 HTTP/1.1 304 Not Modified Date: Mon, 16 Jan 2012 05:48:43 GMT Connection: close Etag: "pv2052dae8634d971149a927231e3ceddf" Cache-Control: no-cache Vary: Accept-Encoding 

I do not understand that both calls return the Cache-Control: no-cache directive to the browser.

However, the second call also returns 304 Not Modified .

Where does the server expect the page to serve data, given that it was instructed not to cache the earlier response?

It is interesting what I do to see the answer in the browser, so the browser seems to have cached the answer, despite the no-cache directive. Why?

Answer 1

A response with Cache-Control: no-cache does not mean that the answer should not be stored at all by the client, but that means:

If the no-cache directive does not specify a field name, then cache MUST NOT use the response to satisfy a subsequent request without successful re-certification with the origin server. This allows the origin server to prevent caching even the caches have been configured to return stale responses to client requests.

Thus, the client is allowed to store the response in the local cache, but it needs to retest the origin server. If the server says that the response stored in the client cache is still valid (for example, response 304), the client is allowed to use the saved response to satisfy the request.