Http 304 & Cache-Control: без кеша

Question

Я вижу ответ ниже на некоторые звонки веб-серверу:

Первоначальный звонок:

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

Последующие звонки:

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

Что мне неясно, так это то, что оба вызова возвращают директиву Cache-Control: no-cache браузеру.

Однако второй вызов также возвращает 304 Not Modified.

Откуда сервер ожидает, что страница будет обслуживать данные, учитывая, что он получил указание не кэшировать более ранний ответ?

Интересно, что я делаю вижу ответ, передаваемый в браузере, поэтому браузер, похоже, кэшировал ответ, несмотря на директиву no-cache.Почему?

Answer 1

A ответ с Cache-Control: no-cache не означает, что ответ вообще не должен храниться на клиенте, а означает:

Если в директиве no-cache не указано имя поля, тогда кеш НЕ ДОЛЖЕН использовать ответ для удовлетворения последующего запроса без успешной повторной проверки с сервером происхождения. это позволяет серверу происхождения предотвращать кеширование даже при использовании кешей настроены на возврат устаревших ответов на клиентские запросы.

Таким образом, клиенту разрешено хранить ответ в локальном кэше, но ему необходимо повторно проверить ответ исходным сервером. Если сервер сообщает, что ответ, сохраненный в кэше клиента, все еще действителен (т.е. ответ 304), клиенту разрешается использовать сохраненный ответ для удовлетворения запроса.