Также дополню, что даже при включенном 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
>> 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