фрагментированное кодирование и соединение: близко друг к другу

Я немного не понимаю, что делать с заголовком «Соединение» при использовании кодирования по частям. Должен ли быть добавлен заголовок «Соединение» (или установлен для поддержания активности, что то же самое, что мы говорим о HTTP 1.1), или он авторизован, чтобы установить его в «Соединение: закрыть». Отправка пустого фрагмента означает конец перевод, а значит ли это окончание соединения? Я думал, что мне нужно будет добавить Connection: close, когда я намерен закрыть соединение после отправки пустого фрагмента, где, если я не добавлю заголовок Connection, он останется открытым

Спасибо


person philippe_44    schedule 01.05.2018    source источник


Ответы (2)


Длина сообщения и управление подключением - это две разные вещи, которые на самом деле не имеют ничего общего друг с другом (за исключением одного случая, когда длина сообщения полностью неизвестна и закрытие соединения является единственным возможным способом обозначить EOF, но это случается редко, и это не твоя ситуация).

Разделение на части применяется только к длине сообщения, где фрагмент нулевой длины обозначает EOF. Если соединение преждевременно закрывается до достижения EOF, сообщение является неполным, и получатель может решить, сохранять / обрабатывать его или нет.

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

Должен ли быть добавлен заголовок «Соединение» (или установлен для поддержания активности, что то же самое, что мы говорим о HTTP 1.1), или это авторизовано, чтобы установить его в Connection: close

Это не имеет ничего общего с разбиением на части. Независимо от формата сообщения, клиент и сервер всегда должны указывать свои намерения в отношении текущего соединения, следует ли его закрыть или оставить открытым. Это достигается за счет наличия или отсутствия заголовка Connection, в зависимости от версии HTTP:

Если используется HTTP 1.0, поведение по умолчанию - close, если Connection: keep-alive не отправлено явно.

Если используется HTTP 1.1+, поведение по умолчанию - keep-alive, если Connection: close не отправлено явно.

Если клиент запрашивает подтверждение активности, сервер решает, соблюдать его или нет. Сервер может либо оставить соединение открытым, либо закрыть соединение.

Если клиент запрашивает закрытие, сервер ДОЛЖЕН соблюдать его и закрыть соединение.

Отправка пустого чанка означает конец передачи, но означает ли это конец соединения?

Нет. Только заголовок Connection делает это. Таким образом, особенно в сценарии keep-alive, соединение остается открытым, чтобы клиент мог повторно использовать существующее соединение для отправки нового запроса после завершения передачи предыдущего ответа.

Я думал, что мне нужно добавить Connection: close, когда я намерен закрыть соединение после отправки пустого фрагмента

Верно, особенно в HTTP 1.1+, где keep-alive - поведение по умолчанию.

где, если я не добавлю заголовок подключения, он останется открытым

Значение пропущенного заголовка Connection зависит от используемой версии HTTP, как описано выше.

person Remy Lebeau    schedule 01.05.2018
comment
Спасибо - Значит, они не связаны, как предполагалось. Я удивлен, увидев, сколько клиентов заявляют, что используют протокол HTTP 1.1 и не поддерживают фрагментированное кодирование. Думаю, совершенно очевидно, что это обязательно. И я должен был добавить, что я говорил только о HTTP 1.1. - person philippe_44; 02.05.2018
comment
Для всех клиентов HTTP 1.1 обязательно распознавать фрагментированные ответы, но для них не обязательно отправлять фрагментированные запросы (хотя все серверы HTTP 1.1 обязаны их распознавать). - person Remy Lebeau; 02.05.2018
comment
И это проблема, с которой я столкнулся. Некоторые клиенты заявляют, что они используют HTTP 1.1 в своем запросе GET, и когда я отвечаю фрагментированным, они немедленно закрывают соединение. Клиенты - это динамики с поддержкой UPnP. Плохая реализация, я думаю - person philippe_44; 02.05.2018

Серверу разрешено отправлять Connection: close при использовании кодирования передачи по частям, это не должно вызывать отключение клиентов до завершения ответа.

Согласно RFC2616 https://tools.ietf.org/html/rfc2616#section-14.10

Например,

   Connection: close

в полях заголовка запроса или ответа указывает, что соединение НЕ ДОЛЖНО считаться «постоянным» (раздел 8.1) после завершения текущего запроса / ответа.

Поскольку ответ не завершен во время отправки фрагментов, соединение не запрещено.

person Tesseract    schedule 27.03.2020
comment
Ответ Реми Лебо более исчерпывающий, чем этот, но быстрое его прочтение не дало мне уверенности в ответе на этот вопрос до его тестирования. - person Tesseract; 27.03.2020