Доброго дня.
1. Директива expires создает два хедера — Expires и Cache-Control. Однако, я бы хотел также добавить другие параметры Cache-Control, например, "public" или "no-store". Сделав это через обычный add_header, на выходе я получу два хедера Cache-Control: в одном "max-age" (созданный директивой expires), в другом "public" (созданный директивой add_header), вместо одного "max-age=..., public". Нет, это не катастрофа, но налицо неэффективное использование bandwidth. Возможные варианты решения: а) опционально мержить значения всех хедеров Cache-Control в один хедер; б) примерживать результат работы expires (max-age или no-cache) к ранним add_header Cache-Control, если таковые были; в) добавить в expires третий параметр, в котором пользователь мог бы указать дополнительные опции Cache-Control (имхо самый адекватный вариант).
2. expires max это max-age на 10 лет и Expires на 2037 год. Однако RFC 2616 (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) гласит: To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. Да, should not это не must not, да и через каких-то 20 с лишним лет вопрос отпадёт сам собой, но всё же. Гугл, кстати, тоже рекомендует максимум год (https://developers.google.com/speed/docs/insights/LeverageBrowserCaching): We recommend a minimum cache time of one week and preferably up to one year for static assets, or assets that change infrequently.
Спасибо за внимание.
1. Директива expires создает два хедера — Expires и Cache-Control. Однако, я бы хотел также добавить другие параметры Cache-Control, например, "public" или "no-store". Сделав это через обычный add_header, на выходе я получу два хедера Cache-Control: в одном "max-age" (созданный директивой expires), в другом "public" (созданный директивой add_header), вместо одного "max-age=..., public". Нет, это не катастрофа, но налицо неэффективное использование bandwidth. Возможные варианты решения: а) опционально мержить значения всех хедеров Cache-Control в один хедер; б) примерживать результат работы expires (max-age или no-cache) к ранним add_header Cache-Control, если таковые были; в) добавить в expires третий параметр, в котором пользователь мог бы указать дополнительные опции Cache-Control (имхо самый адекватный вариант).
2. expires max это max-age на 10 лет и Expires на 2037 год. Однако RFC 2616 (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) гласит: To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. Да, should not это не must not, да и через каких-то 20 с лишним лет вопрос отпадёт сам собой, но всё же. Гугл, кстати, тоже рекомендует максимум год (https://developers.google.com/speed/docs/insights/LeverageBrowserCaching): We recommend a minimum cache time of one week and preferably up to one year for static assets, or assets that change infrequently.
Спасибо за внимание.