Также дополню, что даже при включенном gunzip заголовок Content-Encoding
принудительно удалится, если он был редиректнут с апстрима, а файл
распакуется.
При включенном gzip не проставится второй заголовок Content-Encoding и
не произойдет повторного сжатия.
При текущем положение дел:
1) Включаем gunzip:
Файл распаковываться не будет(заголовка Content-Encoding-то нету),
заголовок не редиректится - получаем кашу.
2) Включаем gzip:
Повторное сжатие не произойдет, второй заголовок не проставится, а
первый заголовок не редиректнется. Итого отдастся нормально сжатый файл,
но без заголовка - опять клиент получит у себя в браузере кашу.
Т.е. есть сценарии, только когда непереданный заголовок
content-encoding создает проблемы, сценарии, когда переданный заголовок
content-encoding как-то помешает, отсутствуют.
On 06/09/2014 07:49 PM, Arteom Pogartsev wrote:
Сомневаюсь, что такой патч может быть принят, тем более, что существует
другой способ сохранить заголовок из ответа бэкенда:
add_header Content-Encoding $upstream_http_content_encoding;
Ровно так и сделано в текущий момент.
Это естественное поведение, желаемое в большинстве случаев.
Почему? Когда может помешать скопированный с бэкенда content-encoding?
Если включено gzip сжатие не для того location, то каша получится в
любом случае, так как файл уже и так сжат.
Проблема может проявиться только, если из-за неправильно настроенного
бэкенда почему-то передался заголовок content-encoding для несжатого
контента.
Или, также возможно, если включен модуль gunzip не для того location.
Потому и предлагается или ввести управлющую опцию, или редиректить
заголовок content-encoding, если не включен gunzip/gzip.
On 06/09/2014 07:15 PM, Валентин Бартенев wrote:
On Sunday 08 June 2014 22:38:49 Arteom Pogartsev wrote:
Hi,
Интересует причина, по которой в src/http/ngx_http_upstream.c поле
redirect для Content-Encoding высталвлено в 0.
Это естественное поведение, желаемое в большинстве случаев.
Соответственно заголовок Content-Encoding не наследуется от бэкенда,
если также имеется заголовок X-Accel-Redirect.
Будет ли принят патч, делающий это поведение хотя бы опциональным? Или
существуют какие-то весомые причины, по которым заголовок
Content-Encoding безусловно отбрасывается?
Сомневаюсь, что такой патч может быть принят, тем более, что существует
другой способ сохранить заголовок из ответа бэкенда:
add_header Content-Encoding $upstream_http_content_encoding;
--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru
