Вопрос по http-headers, http, tcp – Получаете ответ на запрос http без длины контента?

16

У меня маленькая программа отправляет http запрос и получает ответ по протоколу TCP.

Формат моего запроса;

GET / HTTP/1.0
Host: somewebsite.com
{two new line}

Я читаю ответ за строкой из сокета (используя NetworkStream и StreamReader в c #), пока не найду заголовок длины содержимого. Я сохраняю длину, затем продолжаю читать, пока не найду пустую строку. Затем создайте буфер с длиной и получите остаток ответа.

Но у некоторых ответов нет заголовка длины контента. Так что мой подход терпит неудачу. Если я не знаю, сколько байтов я должен получить, когда мне следует остановиться?

Ваш Ответ

2   ответа
6

Увидетьсоответствующая часть спецификации HTTP. In your specific case, if the server does not give content length back, then it MUST be closing the stream upon finishing the response. There is no other reliable way for you (as a client) to know. Regardless of HTTP version. @Julian chunked encoding is indeed a clever upgrade in HTTP/1.1 but is rather specific to streaming and there is no reason why a "plain" webserver would implement it. That is a server which knows the content length before initiating response. And i guess that the OP doesn't have the server under control, otherwise he won't be objecting missing HTTP headers.

Но даже если вы получите заголовок длины контента, выне должен безоговорочно доверять ему, Разработчики серверов тоже являются ошибочными людьми. Воспринимайте это как «наиболее вероятное» ответ, начальное значение для буфера изменяемого размера. Вы все еще должны быть готовы справляться как с меньшими, так и с большими (худший случай).

Ах, конвейерная обработка, хорошо. Я почти удивился, что есть какая-то загадочная функция HTTP, которая позволяет серверу отправлять несколько ответов на один запрос, что, скорее всего, и хочет сделать OP.
Это очень вводит в заблуждение. Если ответ имеет поле заголовка длины содержимого и не использует фрагментированное кодирование, то этоonly информация у вас есть. Если вы получаете меньше контента, его следует считать усеченным. Если вы получаете больше контента, сервер не работает или вы уже просматриваете следующий ответ.
vtmarvin: клиент может использовать конвейерную обработку.
Я скромно спрашиваю объяснения, как чтение следующего ответа может происходить в одном уникальном сокете, когда клиент еще не завершил синтаксический анализ текущего, так что очень маловероятно, что он уже отправил следующий запрос. Я могу понять понижение голоса лучше. В противном случае я не вижу каких-либо существенных разногласий по этому вопросу. Что бы вы сделали, когда вы читаете до объявленной длины контента, а чтение из сокета говорит вам, что осталось еще 2 байта? На самом деле, говоря «тупой сломанный сервер, я больше не буду с вами разговаривать» не применяется так часто, как хотелось бы хорошим программистам.
20

Похожие вопросы