Назад | Перейти на главную страницу

Поддержка понижения версий js / css / image с сервером nginx

У меня есть требование о поддержке понижения версии моего серверного кода.

У меня есть следующая строка в моем файле конфигурации nginx, указывающая, что браузер может кэшировать страницу, но должен проверить сервер, чтобы проверить, изменился ли файл.

add_header Cache-Control "no-cache";

Эта установка отлично работает для меня со всеми обновлениями, выполненными на моем серверном коде.

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

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

add_header Cache-Control "no-store";

Итак, как мне заставить nginx распознавать понижение версии ??

В сценарии без кеширования браузер обычно выдает заголовок If-Modified-Since с запросом GET, чтобы увидеть, изменился ли рассматриваемый файл из кэшированной копии.

Сервер либо:

  1. вернуть ответ 304 - Not Modified
  2. вернуть другой код:
    • 200 - ОК, если дата изменения на сервере позже, чем переданная с заголовком
    • Другое - любой другой код, который может быть возвращен (4xx, 5xx и т. Д.)

Nginx будет использовать измененную временную метку в файле, который он обслуживает, для создания заголовка Last Modified и для сравнения с If-Modified-Since.

В связи с этим обновление метки времени файла с touch /path/to/myfile.ext заставит nginx идентифицировать его как измененный после даты If-Modified-Since и позволит nginx обслуживать файл.

В качестве альтернативы вы должны иметь возможность принудительно выполнить повторную выборку, явно указав заголовок Last Modified в вашей конфигурации nginx, который находится после ожидаемой даты If-Modified-Since. В вашем сценарии это по существу повлечет за собой:

  1. Понизьте свой код
  2. Измените конфигурацию nginx на текущую дату (например,): add_header Last-Modified Mon, 09 Jan 2012 17:07:00 GMT
  3. Перезагрузить nginx

Важно отметить, что если ваши статические активы изменятся после этого, жестко запрограммированный заголовок не будет отражать это изменение (т.е. даже когда вы `` обновляете '' свой код, вам все равно придется вручную изменить config.

Во-первых, «без кеширования» не обязательно означает то, что вы думаете на практике. Я подозреваю, что вы действительно хотите использовать "Cache-Control: max-age = 0, must-revalidate". Некоторые браузеры (Firefox) неправильно трактуют «no-cache» как эквивалент «no-store» и вообще ничего не кешируют на диске. Они просто повторно выбирают весь контент из источника при каждой загрузке страницы, что является ужасной тратой полосы пропускания и отстой для пользователя.

Во-вторых, ваш конкретный вариант использования - это именно то, что ETags были разработаны для простой логики даты только вперед, которая используется без них. (Весь связанный сайт отлично читается по кешированию, а не только по электронным тегам).

Наконец, вам следует рассмотреть возможность именования ваших ресурсов с помощью некоторой формы идентификатора даты (или, еще лучше, хэша содержимого), чтобы вам никогда не приходилось беспокоиться о подобных вещах. Затем вы можете установить cache-control на 1 год. Для этого требуются изменения рабочего процесса и сценарии сборки, хотя многие сайты могут переименовывать файлы и заменять ссылки. Но это то, что делают Google и другие большие парни ...