Разве настройка кэширования автоматически не разрешает кэширование даже без условного запроса?

Question

Для следующего изображения: https://upload.wikimedia.org/wikipedia/commons/7/79/2010-brown-bear.jpg

Заголовка cache-control нет. И на основе здесь , даже если вы ничего не отправляете, он будет использовать значение по умолчанию, равное private. Это значит, что URLSession не должен выполнять условный запрос , чтобы убедиться, что он все еще действует?

Есть ли в заголовках что-нибудь, что позволяет ему делать такой условный запрос? Потому что я не вижу cache-control, max-age, Expires. Единственное, что я вижу, это Last-Modified & Etag, но опять же он должен проверяться на сервере или не указывать что-либо делает его кеширующим бесконечно ?! Я уже прочитал этот ответ , но не обсуждаю этот сценарий.

И все же он кэшируется с помощью URLSession. (Потому что, если я выключаю интернет, он все равно загружается)

Единственное, что я вижу, это "Strict-Transport-Security": max-age=106384710.

Влияет ли это на кэширование? Я уже посмотрел здесь и не верю в это. Исходя из того, что max-age для ключа HSTS, существует только для принудительного доступа к нему из HTTPS в течение определенного периода времени. По достижении максимального возраста возможен также доступ через HTTP.

Это все заголовки, которые я получаю:

Date : Wed, 31 Oct 2018 14:15:33 GMT
Content-Length : 215104
Access-Control-Expose-Headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache, X-Varnish
Via : 1.1 varnish (Varnish/5.1), 1.1 varnish (Varnish/5.1)    
Age : 18581
Etag : 00e21950bf432476c91b811bb685b6af
Strict-Transport-Security : max-age=106384710; includeSubDomains; preload
Accept-Ranges : bytes
Content-Type : image/jpeg
Last-Modified : Fri, 04 Oct 2013 23:30:08 GMT
Access-Control-Allow-Origin : *
Timing-Allow-Origin : *
x-analytics : https=1;nocookies=1
x-object-meta-sha1base36 : 42tq5grg9rq1ydmqd4z5hmmqj6h2309
x-varnish : 60926196 48388489, 342256851 317476424
x-cache-status : hit-front
x-trans-id : tx08ed43bbcc1946269a9a3-005bd97070
x-timestamp : 1380929407.39127
x-cache : cp1076 hit/7, cp1090 hit/7
x-client-ip : 2001:558:1400:4e:171:2a98:fad6:2579

_{Этот вопрос был задан из-за этого комментария}

Answer 1

Разве URLSession не должен выполнять условный запрос, чтобы убедиться, что он все еще действителен?

Пользовательский агент должен выполнить условный запрос из-за

Etag : 00e21950bf432476c91b811bb685b6af

присутствует. Мой рабочий стол Chrome, безусловно, выполняет условный запрос (и возвращает 304 Не изменено).

Но это бесплатно, не

Но пользовательский агент совершенно свободен в выборе. Это совершенно бесплатно смотреть на:

Дата последнего изменения : пт, 04 октября 2013 23:30:08 GMT

и решите, что этот ресурс, вероятно, хорош на следующие пять минут ¹ . И если сетевое соединение не работает, то вполне разумно и правильно отображать кэшированную версию. Фактически ваш браузер будет показывать вам веб-сайты, даже если ваш модем удаленного доступа со скоростью 0,00336 Мбит / с был отключен.

Вы не хотели бы, чтобы ваш браузер ничего не показывал, когда он прекрасно знает, что он может вам что-то показать. Это становится еще более полезным, когда мы говорим о плохом интернет-соединении не из-за медленного набора номера и неработающих серверов, но из-за мобильных вычислений и тарифных планов с измерением данных.

¹ Я говорю 5 минут, потому что в ранних версиях серверы не давали подсказок кешу. Таким образом, браузеры кэшировали вещи, даже не спрашивая. И 5 минут было хорошим номером. И вы использовали Ctrl + F5 (или это было Shift + F5 , или это было Shift + Нажмите или Alt + Нажмите ), чтобы заставить браузер обходить кеш.