Сомневаюсь, что такой патч может быть принят, тем более, что существует
другой способ сохранить заголовок из ответа бэкенда:
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
