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

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru