2012-07-07 2 views
11

Ho un piccolo programma che invia la richiesta http e ottiene risposta con il protocollo TCP.Ottenere risposta della richiesta http senza lunghezza del contenuto?

Formato richiesta;

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

ho letto riga di risposta per riga da presa (utilizzando NetworkStream e StreamReader in C#) fino a trovare intestazione Content-Length. Conservo la lunghezza, quindi continuo a leggere fino a trovare una linea vuota. Quindi creare un buffer con la lunghezza e ricevere il resto della risposta.

Ma alcune risposte non hanno un'intestazione di lunghezza del contenuto. Quindi il mio approccio fallisce. Se non so quanti byte dovrei ricevere, quando dovrei smettere?

risposta

15

In HTTP/1.0? Quando il flusso si chiude.

In HTTP/1.1? Con chunked encoding.

4

Vedere relevant part of HTTP spec. Nel tuo caso specifico, se il server non restituisce la lunghezza del contenuto, DEVE chiudere il flusso al termine della risposta. Non esiste un altro modo affidabile per te (come cliente) di sapere. Indipendentemente dalla versione HTTP. @Julian Chunked Encoding è davvero un aggiornamento intelligente in HTTP/1.1 ma è piuttosto specifico per lo streaming e non vi è alcun motivo per cui un server web "normale" lo implementerebbe. Questo è un server che conosce la lunghezza del contenuto prima di iniziare la risposta. E suppongo che l'OP non abbia il server sotto controllo, altrimenti non metterà in discussione le intestazioni HTTP mancanti.

Ma anche se si ottiene l'intestazione della lunghezza del contenuto, è must not unreservedly trust it. Gli implementatori del server sono anche solo esseri umani fallibili. Prendilo come una risposta "più probabile", valore iniziale per un buffer ridimensionabile. Devi essere ancora pronto a gestire meno e più (nel caso peggiore).

+7

Questo è molto fuorviante. Se la risposta ha un campo di intestazione di lunghezza del contenuto e non usa la codifica Chunked, questa è la * sola * informazione che hai. Se ricevi meno contenuti, il contenuto dovrebbe essere considerato troncato. Se ricevi più contenuti, il serer è rotto o stai già guardando la risposta successiva. –

+0

Sto chiedendo umilmente spiegazioni su come leggere la prossima risposta potrebbe accadere su un unico socket univoco, quando il client non ha terminato l'analisi di quello corrente, quindi è molto improbabile che abbia già inviato la richiesta successiva. Posso capire meglio il downvote. Altrimenti non vedo alcun disaccordo significativo in merito. Cosa faresti quando leggi la lunghezza dichiarata del contenuto e la lettura del socket ti dice che sono rimasti altri 2 byte? In realtà, dire "stupido server rotto, non parlerò più con te" non è applicabile tutte le volte che i programmatori vorrebbero. –

+0

vtmarvin: il client potrebbe utilizzare il pipelining. –