Как бороться с излишне агрессивным браузерным кэшированием?

Question

[Глюкъ Виртуален]

Привет
Я уже использовал все известные мне способы запретить кэширование в браузерах, но ничего не помогло.

Клиент ходит аяксом на API и получает оттуда JSON. Точнее должен ходить, но упорно тащит все из кэша. Это становится совсем неприятным, когда клиенту нужно авторизоваться: вместо токена в ответ он может получить либо старый токен, либо непонятно что.

Настраивать управление кэшированием на сервере совершенно бесполезно: ни Хром, ни Сафари директивам не следуют и тащат все из кэша. Я использовал ?_nocache= как последний способ, но браузерам пофиг. Можно даже подсунуть аяксу левый адрес сервера — эффект будет тот же. То есть создается впечатление, что на самом деле обращения к серверу не было.



Сейчас сервер отдает еще и такие заголовки:
Cache-Control:max-age=10
Date:Fri, 22 Apr 2016 10:07:15 GMT
Expires:Fri, 22 Apr 2016 10:07:25 +0000
Last-Modified:Fri, 22 Apr 2016 10:07:15 GMT

Но все бесполезно, оба браузера делают вид что ходят на сервер, но всегда используют локальный кэш. Кратковременно помогает только полная очистка кэша, но юзер не будет чистить его постоянно... И через некоторое время все начинается заново.

Что делать? Как бороться с этой гадостью?

UPD:
Мобильный Сафари пошел еще дальше. Если залогиниться, срубить Сафари, "удалить кэш и всю историю всех сайтов" в настройках, перезагрузить телефон и зайти снова — без лишних вопросов обнаруживаем себя залогиненными как ни в чем ни бывало...

Answer 1

[Алексей]

Может одинаковый ETag виноват? Или значение nocache не меняется.

Comments

[Глюкъ Виртуален]

Etag сейчас не отдается вообще. В nocache текущий unix timestamp, меняется.

[Алексей]

Про ETag а кажется ступил.
Вообще nocache должно быть достаточно, если значение там реально меняется, добавтье туда какой-нибудь random чтобы втечение секунды ссылка тоже менялась. Expires тоже не мешало бы сделать "вчерашний".

[Глюкъ Виртуален]

Алексей: дак там рандом и есть :( Абсолютно все пофигу.
Похоже, разработчики браузеров воюют между собой "кто кого перекэширует"...

[Алексей]

Вы сами писали что там unix timestamp и частоту обращения по ссылке не указали. Вот я и предположил, что есть вероятность что втечение одной секунды может быть два обращения.
Попробуйте заменить название nocache на myparam (на всякий случай) и добавить random для надежности. Кто знает, может Гугл знает про nocache :)

[Алексей]

Хорошо бы конечно увидеть пациента вживую, но, видимо, это личный кабинет.

[Алексей]

Ну и чисто в порядке перебора вариантов.
Вы на каком этапе добавляете _nocache?
Перед каждым ajax запросом при помощи javascript или один раз при генерации страницы со скриптом?

[Глюкъ Виртуален]

Алексей: Частота обращений — 5...15 секунд.
timestamp добавляется при каждом составлении запроса. Он точно разный, я его в нетворке вижу :)

Про замену nocache и собственно таймштампа на черт-те что уже была мысль: делал два параметра, в одном таймштамп, в другом рандомная строка - без толку. Правда второй параметр тоже содержал слово cache, может быть поэтому и был проигнорирован... Неужели все так по-скотски :(

[Глюкъ Виртуален]

Алексей: заметил что гугловский https://maps.google.com/maps/api/js не кэшируется никогда. Скопировал соотв заголовки и значения оттуда — все равно кешируется :(

[Алексей]

Тогда остается смотреть пациента вживую.
99% где-то есть ошибка, и таких мест много
1% глюк браузера (обоих одновременно)

[Алексей]

Или хотя бы полные отправляемые и принимаемые заголовки когда скрипт загружается и когда берется из кеша.
Как вариант - отправьте туда POST запрос, вряд ли браузер рискнет закешировать POST.

[Глюкъ Виртуален]

Алексей: оба сразу — это скорее намек на сервер...
Сейчас выставил в API вот такую отдачу:

Cache-Control:max-age=0,19803810119629
Connection:keep-alive
Content-Type:application/json
Date:Fri, 22 Apr 2016 10:29:33 GMT
Expires:Fri, 22 Apr 2016 10:29:33 +0000
Last-Modified:Fri, 22 Apr 2016 10:29:33 GMT
Server:nginx/1.8.0
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-XSS-Protection:1; mode=block

Последние полчаса работает нормально, но думаю что ночью как обычно все начнется снова.
Сразу бросилось в глаза Cache-Control:max-age=0,19803810119629. На сервере выставлено 10 сек, у других таких же запросов (они периодические) так и есть 10 сек, а у одного вот такое.

[Алексей]

Cache-Control:max-age=0,19803810119629 - некорректный заголовок, там не должно быть таких дробей. Тут должно быть что-то типа "private, max-age=0, no-cache". Expires вроде вполне нормальные, но для гарантии я бы Expires убавил на годик-другой (хотя бы на пару дней).

[Алексей]

Как быстрое решение - проводить POST запрос.
Не думаю что он будет кешироваться при любых заголовках.

[Глюкъ Виртуален]

Алексей: да, сейчас спасаюсь именно POST, но тут возникает сразу две проблемы:
- это не отвечает стандарту REST
- используемый в API механизм не умеет делать внутренний рероутинг с методом, отличным от GET.

Я не понимаю, откуда появилась дробь... API честно отдает 10 секунд, во всех ответах видны эти 10, а вот один поймал вот с таким чудом.
В API эти 10 сек захардкожены на время экспериментов, со стороны сервера эта подляна исключена.

Answer 2

[Дмитрий]

с такими заголовками оно и будет из кэша брать.

поставьте что-то такое:
'Expires' => 'Wed, 11 Jan 1984 05:00:00 GMT',
'Cache-Control' => 'no-cache, must-revalidate, max-age=0',
'Pragma' => 'no-cache',

у будут у вас всегда актуальные данные.

кэшировать, даже на короткий срок, ответ от апи лучше на стороне клиента.
то есть сервер всегда должен отдавать с заголовками запрещающими любое кэширование.
если нужно что-то кэшировать, кладите ответ + timestamp в локал сторидж, на стороне клиента
затем сравнивайте этот таймстэмп с текущим временем, если он устарел, обновляйте с сервера

Comments

[Глюкъ Виртуален]

Добрый день
Приведенный вами набор из трех устаревших директив не работает уже несколько лет. Я сталкивался с этим примерно в 2012, тогда проблему удалось решить добавлением левого параметра в строку запроса (как-то ?nocache=blablabla). Сейчас война браузеров вышла на новый виток и по всей видимости нужно придумывать что-то новое.

Вчера я еще раз убедился в этом, вы можете это повторить. Укажите Cache-Control:max-age=0, must-revalidate, no-cache и 100% таких запросов будут закэшированы как минимум в Safari и скорее всего в Chrome. Укажите вместо этого реальные Expires и Last-modified как в моем примере — и такие запросы будут кэшироваться куда реже.

В локалсторадже хранится timestamp последнего ответа, он добавляется к другим запросам.
В принципе не страшно если юзер получит обновление новостей на 10 минут позже. Главная жопа в том, что кешируются запросы на авторизацию (даже с добавленным рандомным параметром в виде timestamp), что приводит к полной невозможности работать.

[Дмитрий]

Глюкъ Виртуален: серьезно?
это откуда вы такое прочитали? можете ссылку на спецификацию скинуть?

как раз добавление левого параметра типо ?ver=1 может не корректно обрабатываться некоторыми прокси серверами. они могут его игнорировать.

именно такой набор заголовков выдает WordPress
https://core.trac.wordpress.org/browser/tags/4.5/s...
там оно прекрасно работает

[Глюкъ Виртуален]

dimasmagadan: лолшто? Спецификацию на не совсем честные приемчики в войне браузеров? :)

А, вы просто вопрос не дочитали. Так вот, вкратце: очень похоже что "некоторым прокси-сервером" в данном случае является сам браузер. Потому что на сервер он НЕ ХОДИТ, а дает закэшированный ранее ответ. Несмотря на изменившийся запрос, ага.

[Дмитрий]

Глюкъ Виртуален: сложно вам, наверное, жить.

не верите мне, почитайте вот это
https://speedupyourwebsite.ru/books/speed-up-your-...
там много букв, можно пропустить и с 58 страницы начать.
в самом конце этой странице написано, как запретить кэширование.

там же есть отдельная глава про кэширование в iPhone

на скриншоте, что у вас, я не вижу заголовков, запрещающих кэширование ответа.
браузер вполне обоснованно использует кэш.

вот вам еще, с этого же сайта.
HTTP заголовок Expires. Почему браузер тем не менее обращается к серверу?

[Глюкъ Виртуален]

dimasmagadan: в книжке речь о 2007 годе (сама книжка от 2009), то есть на сегодняшний день это непозволительно устаревшая информация.
Вопрос pxx задан более трех лет назад, это очень и очень давно по меркам развития интернета.

На хамство позвольте не отвечать, спасибо и до свидания.

[Дмитрий]

Глюкъ Виртуален:
>На хамство позвольте не отвечать, спасибо и до свидания.
А где вы хамство нашли? Решил, что ответ в стиле "лолошто", вам будет понятнее.
Если и так не понятно или вас такой же стиль общения в ответ оскорбляет, сочувствую.

И я вас удивлю. Да, книжка от 2009 года, но с тех пор с этими заголовками ничего не поменялось.
Если поменялось, покажите спецификацию.

Браузеры довольно строго следуют этим спецификациям, поэтому считать как "нечестные приемчики в войне браузеров" - неправильно.

Единственная вещь, которая может не корректно обрабатываться, это параметры после "?". Некоторые прокси сервера могут все, что после знака вопроса отбрасывать.
Почитайте книжку по ссылке, там этот момент так же описывается.

Вот вам ссылка на статью от этого года, но на английском. Там точно те же заголовки используются.
https://www.keycdn.com/blog/a-guide-to-http-cache-...

Answer 3

[Dmitry Tallmange]

Присоединяюсь к Алексей. Лично у меня все прекрасно работает и в хроме, и в лисе. Веротяно, здесь закралась какая-то ошибка с Вашей стороны.

Comments

[Глюкъ Виртуален]

Какая ошибка может быть в GET-запросе?
Которая вдруг сама по себе исчезает, если почистить браузерный кэш. И через некоторое время появляется снова.