HTTP: отключить сокет для записи после отправки запроса?

Question

Как правильно использовать сокет, используемый клиентом HTTP после передачи запроса?Или он должен оставаться открытым (двунаправленным), пока не будет получен полный ответ?Если да, то как сервер определяет конец тела запроса?

Согласно http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4, закрытие сокета не является опцией для запроса.Это не звучит логично для меня - почему полузакрытое TCP-соединение должно быть проблемой для сервера, если клиент не пытается ничего передавать после закрытия своей половины сокета?В конце концов, клиент все еще может получать данные.

Мне кажется, что отключение части записи сокета было бы очень практичным способом сообщить серверу, что запрос завершен.http://docs.python.org/howto/sockets.html#disconnecting даже особо упоминается тот случай использования.

Если это действительно неправильный способ сделать это, какая альтернатива?Действительно ли мне всегда нужно отправлять «Content-length» или использовать фрагментированный транспорт, чтобы сервер мог правильно найти конец запроса?Как это работает для запросов с неизвестной длиной тела?

Answer 1

Transfer-Encoding: chunked специально предназначен для отправки данных с неизвестной длиной тела, как для запросов, так и для ответов.Конец данных определяется путем получения чанка, размер полезной нагрузки которого равен 0. Если вы не отправляете запрос chunked, вы должны вместо этого отправить Content-Length.

Answer 2

Вы говорите об этом?:

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

Я думаю, что текст говорит о полном закрытии, вы можете сделать половину (написать) -закрыть.Я не уверен, что это совместимый с HTTP способ сделать это, но я думаю, что большинство серверов примут это.

Что касается вашего второго вопроса, просто используйте chunked encoding:

ВсеПриложения HTTP / 1.1, которые получают объекты, ДОЛЖНЫ принять «чанкованное» кодирование передачи (раздел 3.6), что позволяет использовать этот механизм для сообщений, когда длина сообщения не может быть определена заранее.