Отключение chunked в nginx. Чем грозит?

Question

[script88]

Чем грозит chunked_transfer_encoding off в определенном location nginx, если в ответ серверу планируется отправлять большое кол-во данных и какой максимальный объем данных nginx сможет принять?

Answer 1

[VBart]

Чем грозит chunked_transfer_encoding off?
Грозит это отключением HTTP Keep-Alive при отсутствии Content-Lenght.

Какой максимальный объем данных nginx сможет принять?
Это не зависит от значения директивы chunked_transfer_encoding.
Если речь идет о буферизации и проксировании HTTP(S), то смотрите описание директивы proxy_buffering:
nginx.org/r/proxy_buffering/ru

Comments

[VBart]

Я посмотрел с точки зрения nginx-а. Но видимо вопрос был гораздо шире, тогда грозит ещё обрезанными страницами/файлами, которые клиент считает целыми, в случае ошибки и разрыва соединения в процессе передачи ответа.

[script88]

Да действительно отключение keep-alive произошло

Answer 2

[ctajiuh]

Из вики: Без механизма сhunked transfer encoding с каждым HTTP пакетом необходимо указывать заголовок Content-length, чтобы клиент мог найти конец передаваемого сообщения.

Comments

[ctajiuh]

Нечаянно отправил не все:
Возможно, при неправильном content-lenght будет кривить с выдачей данных?

[VBart]

«При неправильном content-lenght» у вас будут проблемы в любом случае.

[VBart]

p.s. формулировка из русскоязычной википедии некорректна.

[VBart]

p.p.s. только сейчас заметил, отдельно доставляет изобретенный термин к несуществующей сущности: «HTTP пакет».

Answer 3

[egorinsk]

chunked encoding используется, чтобы сервер мог отдавать ответ по кускам. Если его отключить, то сервер должен сохранить ответ от бекенда в буфер в памяти или на диске и отдавать одним куском. Это менее выгодно в плане производительности.

Comments

[VBart]

Это не так. Откуда эти домыслы вообще берутся?

RFC 2616 говорит четко и ясно:
tools.ietf.org/html/rfc2616#section-4.4

Как можно видеть, сервер ничего не должен и может обозначить окончание передачи не только нулевым чанком, но и закрытием соединения.

[egorinsk]

Наверно, я непонятно написал, если вы не так меня поняли. Я же нигде не писал про нулевой чанк.

Полез, кстати, в упомянутый вами RFC проверить, зачем нужен этот chunk encoding, и понял, что авторы RFC тоже толком не знают:

> This allows dynamically produced content to be transferred along with the information necessary for the recipient to verify that it has received the full message.

[VBart]

Вы написали:
1. чтобы сервер мог отдавать ответ по кускам — это не так, сервер может отдавать ответ по кускам и без chunked encoding.
2. Если его отключить, то сервер должен сохранить ответ от бекенда в буфер — и это тоже не верно, не должен.

Не очень понял, как вы сделали такой вывод, что авторы не знают и при этом привели цитату, которая вполне ясно дает понять зачем он нужен.

[egorinsk]

Признаю, тут я ошибся.

[VBart]

Я дополнил свой ответ ниже, чтобы пояснить, что авторы RFC имели ввиду в вашей цитате.