Как запретить lighttpd кэшировать статические файлы, даже если они были изменены на диске?


10

Я использую lighttpd для обслуживания статических файлов. У меня есть куча изображений в каталоге, которые я регулярно обновляю. Это изменит содержимое файла (и размер файла), а также дату изменения, но не их имя файла.

Когда я получаю доступ к файлам через http, обновления не принимаются во внимание и lighty обслуживает старый файл. Я могу вручную переименовать файл во что-то другое, тогда lighttpd выдаст ошибку 404, и если я переименую свой файл обратно, я получу правильную обновленную версию. Похоже, что lightty использует какой-то собственный механизм кеширования (что нормально) для возврата статических файлов. К сожалению, кажется, что этот механизм не обновляется при изменении файлов.

Я проверил через Wireshark, и мой браузер действительно делает запрос к файлу, это не проблема кэширования браузера. Он возвращает 200 OK при запросе его из пустого кэша и 304 Not Modified в противном случае, как и ожидалось. Но файл возвращается с неправильным заголовком Last-Modified, который не отражает реальную дату последней модификации.

Может быть, есть какая-то директива config, о которой я не знаю?

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

Обновление для всех, кто следит за этим вопросом: я нашел виновника. Если я обновляю статический файл, Lighty не возвращает новый контент, но возвращает новый Content-Length в своих заголовках, что приводит к отображению мусора. Если я сожму файл с помощью mod_compress, проблема исчезнет, ​​так как mod_compress использует свою собственную систему кэширования. К сожалению, я не могу сжать все файлы (например, файлы изображений). Так что это только частичное исправление, но я вернусь к нему позже и быстро найду решение.

Ответы:


6

Я наконец нашел проблему. И это происходит от VirtualBox.

При редактировании файла на хосте (Win) lighttpd в гостевой системе (Linux) неправильно обновляет содержимое файла (но корректно обновляет размер файла), возвращая, таким образом, обрезанное или искаженное содержимое.

Демонтирование моих общих дисков и их повторное монтирование или редактирование файлов непосредственно в гостевой системе решило проблему.

Мне потребовалось 6 месяцев, чтобы наконец понять это.


3

Вы не упоминаете, установлен ли у вас mod_cache или нет? Этот модуль по умолчанию «включен» при установке.

Я не хочу предлагать это, но помогает ли включение Etags?


mod_cache не установлен. ETag включены (но inode не используется для генерации ETag). Я попытался включить inode или отключить ETag, но безрезультатно.
Pixelastic

2

Попробуйте установить кеширование статов в «отключен»:

server.stat-cache-engine = "disable'

Спасибо, но это не имеет никакого эффекта. Однако я не знал этой директивы, и она может пригодиться позже.
Pixelastic

Может быть посредник между вами и сервером? Попробуйте перезагрузить сервер и получить доступ к тому же файлу. Вы используете mod_compress?
Алексей Корзун

Я использую Ubuntu VM на хосте Windows 7. Lighty находится в ВМ. Я не думаю, что здесь может быть проблема с прокси. Я перезапустил сервер, но это не очищает легкий кеш. Я использую mod_compress, но не на этих файлах. Я попробую перезапустить всю виртуальную машину и отключить mod_compress, чтобы посмотреть, изменится ли она. Спасибо за идеи.
Pixelastic

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

Извините за спам-комментарии: отключение mod_compress ничего не меняет и не перезапускает всю ВМ.
Pixelastic

2

Этот вариант lighttpd работал для меня

server.network-backend = "writev" 

Работая как очарование для меня, на виртуальной машине Debian на рабочем столе Debian, спасибо!
Иван

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.