Предоставляет ли HTTP/1.1 возможность ограничивать конец запроса, закрывая соединение?

RFC2616 part 4.4 specifies how the end of the message is determined in HTTP/1.1. Item 5 in that section specifies that the server may close the connection to indicate the response is finished.

В нем также говорится, что ограничение такого запроса невозможно. Тем не менее, TCP позволяет клиенту закрыть его конец и продолжить получать ответ. Я даже проверил это; оно работает.

Вопросов:

  • Почему стандарт 1999 года говорит, что это невозможно, когда это действительно возможно? TCP был хорошо установлен к тому времени и к тому времени поддерживал половину закрытия (возможно, с 1974 года).

  • Является ли это нарушением протокола для клиента, чтобы закрыть соединение, чтобы указать конец запроса?

Пожалуйста, не обращайте внимания на то, является ли это хорошей идеей: я знаю, как вы иногда не можете точно сказать, было ли соединение закрыто специально или просто сломалось, и как это имеет смысл, чтобы открыть соединение для повторного использования позже.

4
nl ja de
@symcbean Правильно, он не был закрыт. Это было полузамкнуто, и я думаю, это еще один способ сказать, что я отправил пакет FIN, но другой конец остался открытым, т. Е. Точно так же, как вы говорите.
добавлено автор Roman Starkov, источник
@symcbean Я не уверен, что вы думаете. Этот вопрос касается не того, как TCP должен вести себя вообще. Кроме того, полузакрытые соединения не являются чем-то странным; это надлежащим образом поддерживаемая функция .
добавлено автор Roman Starkov, источник
@symcbean Если это то, что вы подразумеваете под «отправкой всего запроса, завершением запроса запроса, ожиданием ответа», то да. Сети TCP эмулируют потоки байтов, где поток каждого направления может быть закрыт отдельно для сигнала конца потока. Можете ли вы указать на проблему в моем мышлении о TCP , вместо проблемы в , как я пришел к выводу ?
добавлено автор Roman Starkov, источник
@symcbean Это совершенно не имеет значения. Нет reason , вам следует «удивляться», что TCP имеет половину закрытия, когда он определен в RFC 793, и это, в свою очередь, не является необходимым следствием сетей коммутации пакетов как таковых. Ваше утверждение о «большинстве HTTP-клиентов» не содержит воды. Ваше последнее предложение не относится ни к чему, что было сказано здесь. Короче говоря, ваш пункт ускользает и от меня.
добавлено автор EJP, источник
Возможно, потому, что спецификация написана так, чтобы быть независимой от протокола соединения, и поэтому они не хотели слишком полагаться на функции, которые могут отсутствовать у других протоколов
добавлено автор Frederick Cheung, источник
Похоже, что вы немного странствуете с картой, но мне действительно интересно узнать, как > вы протестировали получение сообщения после закрытия соединения? Я подозреваю, что соединение не было закрыто - только что вы отправили пакет FIN.
добавлено автор symcbean, источник
Поведение TCP не определено приложением, поэтому сделать выводы о том, как TCP должен вести себя из HTTP RFC, не является плодотворным преследованием? Учитывая природу сети с коммутацией пакетов, я не очень удивлен тем, что приложение все еще может получать и обрабатывать данные, отправленные после испускания FIN. Но обычно клиент закрывает коннект, большинство HTTP-клиентов не закрывают соединение с FIN, они используют RST, а в случае сервера, отправляющего пакет FIN, а затем отправка последующих пакетов данных не должна быть возможной ( без прерывания бит MITM).
добавлено автор symcbean, источник
@romkyns: ваш анализ, по-видимому, основан на взаимодействии клиента и сервера. Сети TCP не предназначены для работы таким образом.
добавлено автор symcbean, источник

1 ответы

Он не говорит, что полузакрытие невозможно. Он просто говорит, что «закрытие соединения не может использоваться для обозначения конца тела запроса», что верно. Он просто не рассматривает возможность полузакрытия так или иначе. Поскольку это не упоминается в RFC, я бы сказал, что использование этого будет нарушением протокола, и у вас не должно быть оснований ожидать, что серверы будут реагировать соответственно: например, сервер будет иметь право просто забыть запрос и закройте соединение при получении FIN.

3
добавлено
Более того, nginx работает именно так. mailman.nginx.org/pipermail/nginx/2008-September/007388. HTML
добавлено автор darkk, источник