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

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

Начальный звонок:

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. Зачем?

1 ответ

Решение

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

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

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

Другие вопросы по тегам