<div dir="ltr"><div><div><div>параллельный вопрос.<br></div>если мы отдаем Cache-Control, он по RFC более приоритетный, чем Expires, правильно ?<br><br></div>и доля клиентов HTTP/1.0 (которые понимают Expires, но не понимают Cache-Control) в большинстве случаев в районе нуля ?<br><br></div>может сделать доп. крутилку (чтобы не менять дефолтное поведение), которая бы позволяла не отдавать Expires ?<br></div><div class="gmail_extra"><br><div class="gmail_quote">25 февраля 2016 г., 13:41 пользователь 5lava <span dir="ltr"><<a href="mailto:nginx-forum@forum.nginx.org" target="_blank">nginx-forum@forum.nginx.org</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Доброго дня.<br>
<br>
1. Директива expires создает два хедера — Expires и Cache-Control. Однако, я<br>
бы хотел также добавить другие параметры Cache-Control, например, "public"<br>
или "no-store". Сделав это через обычный add_header, на выходе я получу два<br>
хедера Cache-Control: в одном "max-age" (созданный директивой expires), в<br>
другом "public" (созданный директивой add_header), вместо одного<br>
"max-age=..., public". Нет, это не катастрофа, но налицо неэффективное<br>
использование bandwidth. Возможные варианты решения: а) опционально мержить<br>
значения всех хедеров Cache-Control в один хедер; б) примерживать результат<br>
работы expires (max-age или no-cache) к ранним add_header Cache-Control,<br>
если таковые были; в) добавить в expires третий параметр, в котором<br>
пользователь мог бы указать дополнительные опции Cache-Control (имхо самый<br>
адекватный вариант).<br>
<br>
2. expires max это max-age на 10 лет и Expires на 2037 год. Однако RFC 2616<br>
(<a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html" rel="noreferrer" target="_blank">https://www.w3.org/Protocols/<wbr>rfc2616/rfc2616-sec14.html</a>) гласит: To mark a<br>
response as "never expires," an origin server sends an Expires date<br>
approximately one year from the time the response is sent. HTTP/1.1 servers<br>
SHOULD NOT send Expires dates more than one year in the future. Да, should<br>
not это не must not, да и через каких-то 20 с лишним лет вопрос отпадёт сам<br>
собой, но всё же. Гугл, кстати, тоже рекомендует максимум год<br>
(<a href="https://developers.google.com/speed/docs/insights/LeverageBrowserCaching" rel="noreferrer" target="_blank">https://developers.google.<wbr>com/speed/docs/insights/<wbr>LeverageBrowserCaching</a>):<br>
We recommend a minimum cache time of one week and preferably up to one year<br>
for static assets, or assets that change infrequently.<br>
<br>
Спасибо за внимание.<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?21,264815,264815#msg-264815" rel="noreferrer" target="_blank">https://forum.nginx.org/read.<wbr>php?21,264815,264815#msg-<wbr>264815</a><br>
<br>
______________________________<wbr>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></blockquote></div><br></div>