На главную

Комментарии

анонимно

Last-Modified



Задача: на сайте используется набор javascript-библиотек, которые сливаются php-скриптом в один файл с названием вида 78472581267468236825748923.js (где цифры - имплод номеров версий каждой отдельной библиотеки), а контент оптимизирован и (может быть) как-то упакован. Планируется, что сий файл будет сидеть в кеше (а по размеру он довольно большой) и когда версия хоть одной из библиотек изменится - изменится имя файла и он будет заново запрошен с сервера. Все счастливы, траффик сэкономлен, дети смеются, Санта Клаус раздаёт подарки, мир во всём мире.

Как же дело обстоит на самом деле? В один прекрасный момент вы замечаете, что траффик у вас совсем не убавился и посмотрев статистику обнаруживаете, что ваш файлик с красивым именем 78472581267468236825748923.js таскается с сервера при каждом запросе и ну никак не хочет залезать в кеш браузера.

Начинаем копать глубже и при сравнении хедеров нашего файла и обычного статичного js обнаруживаем, что у последнего в хедере присутствует параметр "Last-Modified: Wed, 10 Sep 2008 07:01:14 GMT", определяющий дату обновления файла. В нашем же файле параметр сий отсутствует и сервер каждый раз шлёт ответ клиенту "200 ОК" с полным контентом.

Гуглим. Пишем принудительную отправку этого параметра в хедере. Не шлётся и всё - хоть убейся.

На различных форумах в сети есть много логичных объяснений. Например, "хренли слать дату обновления скрипта, если контент динамический?" (действительно, возразить сложно).

Грешил сначала на апач (думал, он отправляемые мной хедеры парсит и пропускает только то, что ему угодно).

Попробовал активировать для моего файла xBitHack. Появились первые подвижки - в хедере возник "Last-Modified", однако, ссылался он на текущую дату/время и изменениям не поддавался.

Потом думал, что пхп не хочет мои хедеры отдавать. 10 раз проверил все возможные варианты синтаксиса, генерацию даты, генерацию хеш-ключа ETag - ноль реакции.

В конечном итоге была найдена информация, что апач будет отдавать Last-Modified только если у файла есть разрешение на execute для группы. Для chmod пришлось тоже писать скриптик, т.к. ходим к хостеру самбой.

И, о чудо, вдруг всё заработало! )))

 

 Механизм определения обновления через хеш ETag описывать не буду - он будет в первой 10 выдачи в гугле по запросу "etag".

,

← Вернуться к журналу «Узелки на память...»

Комментарии

  • Так вот проблема-то как раз в том, что файло хоть и кладётся исправно в кеш, но оттуда не вынимается, а каждый раз заново реквестается с сервера ))

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

  • Да, за ссылку спасибо.

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

  • я тоже по самбе хожу, и "execute для группы" не требуется.
    Для кеширования в .htaccess написано так:
    ExpiresActive On
    ExpiresByType image/png "access plus 1 month"
    ExpiresByType image/gif "access plus 1 month"
    и т.д.
    более подробно про клиентскую оптимизацию можно почитать тут:
    http://webo.in/
    можно ещё файл переименовать из *.js в *.gz, а на клиенте распаковывать (mod_deflate), тоже трафик экономит.

  • Куда сохранять? Кто будет сохранять?
    А если изменения происходят 10 раз за сутки?

  • если этот js файл один для всех пользователей, почему бы его после сливания всех в один не сохранять просто?

  • ахуеть

Новый комментарий

Скрытое сообщение