Изображение не сохраняется в кеше, хотя заголовки установлены

Question

Изображение не сохраняется в кеше, хотя заголовки установлены

0

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

http://runrpg.net/assets/images/screenshots/placeit_outdoor_wide.jpg

Я понимаю, что правильные заголовки должны быть установлены, и в настоящее время заголовок ответа выглядит следующим образом:

HTTP/1.1 200 OK
Date: Sat, 04 Jan 2014 16:35:53 GMT
Server: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.5.3 mod_perl/2.0.8-dev
    Perl/v5.16.3
Last-Modified: Sat, 30 Nov 2013 01:37:52 GMT
ETag: "1dac5-4ec5afebf3c00-gzip"
Accept-Ranges: bytes
Cache-Control: max-age=2592000
Expires: Mon, 03 Feb 2014 16:35:53 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: image/jpeg

Как вы можете видеть, заголовок "Expires" установлен в "Mon, 03 Feb 2014 16:35:53 GMT", и я также включил "Cache-Control: max-age = 2592000".

Можете ли вы мне помочь и рассказать мне, что мне не хватает? Ваша помощь будет очень оценена.

Благодарю!

DerJacques 04 янв. 2014, в 18:27

Источник

0

Я думаю, что это как-то связано с браузером. Когда вы пытаетесь получить доступ к изображению напрямую, оно получает последнюю копию. Но если на то же изображение ссылаются на другую страницу, оно будет вести себя нормально и кэшировать его.
Parthik Gosar 04 янв. 2014, в 17:13
0

Спасибо за ваш ответ! К сожалению, похоже, что это не так. Изображение используется в качестве фонового изображения на следующей странице: ссылка На этой странице изображение также не кэшируется.
DerJacques 04 янв. 2014, в 17:37
0

Немного ОТ, но: есть ли причина для сжатия изображения? Я ожидаю, что это увеличит передаваемый контент.
DaSourcerer 04 янв. 2014, в 17:56
0

Теперь я совершенно новичок в этом, но я подумал, что сжатие изображений означает, что передаваемый контент уменьшается? Из тестов я обнаружил, что в этом случае размер изображения уменьшается на 11%, но, может быть, я что-то неправильно понимаю?
DerJacques 04 янв. 2014, в 18:18
0

@DerJacques: Это может произойти, только если они не были должным образом сжаты с помощью алгоритма JPEG. В любом случае, HTTP-сжатие - действительно неподходящее место для этого.
DaSourcerer 04 янв. 2014, в 18:27
0

Хорошо, спасибо! Я определенно изменит это. К счастью, это должно быть очень легко сделать. Я полагаю, у вас нет ответа на оригинальные вопросы? Есть идеи, почему на runrpg.net не кэшируются никакие изображения, css или js файлы?
DerJacques 04 янв. 2014, в 18:38
0

Я все еще ломаю голову над этим. Я бы попробовал добавить public в заголовок Cache-Control вашем месте.
DaSourcerer 04 янв. 2014, в 18:43
0

Я пытался сделать это (и в настоящее время он «включен»), но все равно нет никакой разницы. Действительно странное поведение, но есть кое-что, что я должен упустить ..
DerJacques 04 янв. 2014, в 18:48
0

Особенно удивительно, что в этом ответе почти нет разницы ... Мой Firefox тоже плохо себя ведет, я почти подозреваю, что с вашим сервером что-то не так.
DaSourcerer 04 янв. 2014, в 18:54
0

Мне кажется, ты прав! Мне просто странно, что браузер зависит от сервера, хотя заголовки кэша установлены правильно. Может сервер должен вернуть 304?
DerJacques 04 янв. 2014, в 18:59
0

Это действительно должно. Смотрите мой ответ ниже.
DaSourcerer 04 янв. 2014, в 19:03

Показать ещё 9 комментариев

Теги:

html

image

caching

http

1 ответ

Ещё вопросы

Я думаю, что это как-то связано с браузером. Когда вы пытаетесь получить доступ к изображению напрямую, оно получает последнюю копию. Но если на то же изображение ссылаются на другую страницу, оно будет вести себя нормально и кэшировать его.
Спасибо за ваш ответ! К сожалению, похоже, что это не так. Изображение используется в качестве фонового изображения на следующей странице: ссылка На этой странице изображение также не кэшируется.
Немного ОТ, но: есть ли причина для сжатия изображения? Я ожидаю, что это увеличит передаваемый контент.
Теперь я совершенно новичок в этом, но я подумал, что сжатие изображений означает, что передаваемый контент уменьшается? Из тестов я обнаружил, что в этом случае размер изображения уменьшается на 11%, но, может быть, я что-то неправильно понимаю?
@DerJacques: Это может произойти, только если они не были должным образом сжаты с помощью алгоритма JPEG. В любом случае, HTTP-сжатие - действительно неподходящее место для этого.
Хорошо, спасибо! Я определенно изменит это. К счастью, это должно быть очень легко сделать. Я полагаю, у вас нет ответа на оригинальные вопросы? Есть идеи, почему на runrpg.net не кэшируются никакие изображения, css или js файлы?
Я все еще ломаю голову над этим. Я бы попробовал добавить public в заголовок Cache-Control вашем месте.
Я пытался сделать это (и в настоящее время он «включен»), но все равно нет никакой разницы. Действительно странное поведение, но есть кое-что, что я должен упустить ..
Особенно удивительно, что в этом ответе почти нет разницы ... Мой Firefox тоже плохо себя ведет, я почти подозреваю, что с вашим сервером что-то не так.
Мне кажется, ты прав! Мне просто странно, что браузер зависит от сервера, хотя заголовки кэша установлены правильно. Может сервер должен вернуть 304?
Это действительно должно. Смотрите мой ответ ниже.

DaSourcerer · Accepted Answer · 2014-01-04T16-45-00.000Z

Скорее всего, это связано с тем, что ваш сервер неправильно проверяет ETags. Хотя проверка кэша через заголовок Last-Modified отлично работает:

$ HEAD -H "If-Modified-Since: Sat, 30 Nov 2013 01:37:52 GMT" http://runrpg.net/assets/images/screenshots/placeit_outdoor_wide.jpg
304 Not Modified
Cache-Control: max-age=290304000, public
Connection: close
Date: Sat, 04 Jan 2014 19:01:30 GMT
ETag: "1dac5-4ec5afebf3c00"
Server: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.5.3 mod_perl/2.0.8-dev Perl/v5.16.3
Expires: Thu, 09 Jan 2014 19:01:30 GMT
Client-Date: Sat, 04 Jan 2014 19:01:30 GMT
Client-Peer: 80.70.3.110:80
Client-Response-Num: 1

То же самое нельзя сказать и с ETags:

$ HEAD -H 'If-None-Match: "1dac5-4ec5afebf3c00-gzip"' http://runrpg.net/assets/images/screenshots/placeit_outdoor_wide.jpg
200 OK
Cache-Control: max-age=290304000, public
Connection: close
Date: Sat, 04 Jan 2014 19:02:24 GMT
Accept-Ranges: bytes
ETag: "1dac5-4ec5afebf3c00"
Server: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.5.3 mod_perl/2.0.8-dev Perl/v5.16.3
Vary: Accept-Encoding
Content-Length: 121541
Content-Type: image/jpeg
Expires: Thu, 09 Jan 2014 19:02:24 GMT
Last-Modified: Sat, 30 Nov 2013 01:37:52 GMT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: origin, x-requested-with, content-type, X-Titanium-Id
Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS
Access-Control-Allow-Origin: http://127.0.0.1:8020
Client-Date: Sat, 04 Jan 2014 19:02:24 GMT
Client-Peer: 80.70.3.110:80
Client-Response-Num: 1

Итог: проблема заключается в том, что ваш сервер, а не клиенты. Это, похоже, известная проблема с Apache 2.4.x. Быстрое решение этого - отключить ETags:

FileETag None

Спасибо большое за помощь! Этот ответ был очень полезен, и я рассмотрю проверку ETag на стороне сервера. По крайней мере, теперь я знаю, где искать! :) Еще раз спасибо!
Быстрое добавление: кеш работает очень хорошо, когда я использую ваше быстрое решение и выключаю ETag. Еще раз спасибо!
@DerJacques Совсем нет. Благодаря вашему вопросу, теперь я знаю об этой проблеме;)