Здравствуйте, Лазар Бешкенадзе, Вы писали:
ЛБ>https://www.rfc-editor.org/rfc/rfc9111#name-no-cache-2
ЛБ>This allows an origin server to prevent a cache from using the response to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
ЛБ>Страничка имеет это дело:
ЛБ>ЛБ>Cache-Control: no-cache
ЛБ>
ЛБ>Но браузер вообще не обращается к серверу а загружает сохраненную версию.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control
Обратите внимание , что
no-cache
это не означает "не кэшировать". no-cache позволяет кэшам сохранять ответ, но требует от них повторной проверки перед повторным использованием. Если значение "не кэшировать", которое вы хотите, на самом деле "не сохранять", то
no-store
это директива для использования.
Ещё можно по взрослому установить
Expires: Thu, 1 Jan 1970 00:00:01 GMT
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Expires
ЛБ>ОС — Android
ЛБ>Browser — Chrome
Мобильная ос и браузер для работы в сетях с платным трафиком.
ЛБ>Во-вторых почему без обращения к серверу?
ЛБ>Вот что делает браузер:
Используй нормальный браузер
https://www.rfc-editor.org/rfc/rfc9111#name-no-cache-2
The no-cache response directive, in its unqualified form (without an argument), indicates that the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see Section 4.3.
This allows an origin server to prevent a cache from using the response to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
Страничка имеет это дело:
Cache-Control: no-cache
Но браузер вообще не обращается к серверу а загружает сохраненную версию.
Устройство — планшет Samsung.
ОС — Android
Browser — Chrome
Выбираю Close all и окошко браузера улетает вверх. Выключаю планшет — Power off.
Включаю его.
Открываю Chrome и мне показывают мою страничку. Во-первых для чего? Я не просил.
Во-вторых почему без обращения к серверу?
Вот что делает браузер:
1. Открывает соединение
2. Закрывает соединение
3. Открывает соединение
4. Запрашивает /favicon.ico и получает 404
И непонятно для чего закрывать и тут же открывать соединение.
-
Здравствуйте, Stanislaw K, Вы писали:
ЛБ>>This allows an origin server to prevent a cache from using the response to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
ЛБ>>Но браузер вообще не обращается к серверу а загружает сохраненную версию.
SK> это не означает "не кэшировать".
Где я писал что это означает "не кэшировать"? Я выше подчеркнул главное.
SK>SK>Expires: Thu, 1 Jan 1970 00:00:01 GMT
SK>
Страница вообще не использует время. Управление кэшированием через Etag. И мне нужно чтобы браузер кэшировал страницу но при этом каждый раз делал условный запрос.
SK>Используй нормальный браузер
Не неси чушь. Какая разница что использую я? Важно что использует он. А он использует Chrome.
-
Здравствуйте, Лазар Бешкенадзе, Вы писали:
ЛБ>>>Но браузер вообще не обращается к серверу а загружает сохраненную версию.
SK>> это не означает "не кэшировать".
ЛБ>Где я писал что это означает "не кэшировать"? Я выше подчеркнул главное.
ага! (1)
SK>>SK>>Expires: Thu, 1 Jan 1970 00:00:01 GMT
SK>>
ЛБ>Страница вообще не использует время. Управление кэшированием через Etag. И мне нужно чтобы браузер кэшировал страницу но при этом каждый раз делал условный запрос.
SK>>Используй нормальный браузер
ЛБ>Не неси чушь. Какая разница что использую я? Важно что использует он. А он использует Chrome.
Разница в том, что мобильная ОС и мобильный браузер, предполагают по умолчанию медленный лимитный канал с платным трафиком. Исходя из этого стратегия работы с объектами в кэше
несколько отличается от
ожиданий мягких рекомендаций стандарта.
Можно попробовать поиграться с комбинациями параметров
Cache-Control: no-cache, must-revalidate, private
Но играя с параметрами иметь в виду что на другим билде браузера поведение может изменится без предупреждения.
Так же непредсказуемо влияние прокси перед браузером клиента.
Это то самое "ага!(1)" — запросто может быть посредник между твоим сервером и им, и браузер клиента таки пытается обратится к серверу. но отвечает ему прокси.
Это может быть как корпоративный проксик, о котором клиент не в курсе, CDN, или прокси мобильного оператора, или "анти"вирус.
Здравствуйте, Stanislaw K, Вы писали:
SK>Можно попробовать поиграться с комбинациями параметров
SK>SK>Cache-Control: no-cache, must-revalidate, private
SK>
Не помогает. Он делает revalidation только если выбрать Refresh.
SK>Так же непредсказуемо влияние прокси перед браузером клиента.
Вот это уже проблема клиента. А сейчас я тестирую в локальной сети — есть сервер, планшет и Wi-Fi маршрутизатор. Может, конечно, proxy сидит прямо у меня в планшете но я его туда не ставил.
-
