2012-07-07 41 views
11

Tengo un pequeño programa que envía una solicitud http y obtiene respuesta con el protocolo TCP.Obteniendo la respuesta de la solicitud http sin contenido-longitud?

Mi formato de solicitud;

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

leí línea de respuesta por la línea de la toma (usando NetworkStream y StreamReader en C#) hasta que encuentre cabecera Content-Length. Guardo la longitud, luego sigo leyendo hasta encontrar una línea vacía. Luego crea un buffer con la longitud y recibe el resto de la respuesta.

Pero algunas respuestas no tienen un encabezado de longitud de contenido. Entonces mi enfoque falla. Si no sé cuántos bytes debería recibir, ¿cuándo debería parar?

Respuesta

15

En HTTP/1.0? Cuando la secuencia se cierra.

En HTTP/1.1? Con chunked encoding.

4

Ver relevant part of HTTP spec. En su caso específico, si el servidor no devuelve la longitud del contenido, DEBE estar cerrando la transmisión al finalizar la respuesta. No hay otra manera confiable para que usted (como cliente) lo sepa. Independientemente de la versión HTTP. La codificación fragmentada de Julian es, de hecho, una actualización inteligente en HTTP/1.1, pero es bastante específica para la transmisión y no hay ninguna razón por la que un servidor web "simple" la implemente. Es un servidor que conoce la longitud del contenido antes de iniciar la respuesta. Y supongo que el OP no tiene el servidor bajo control, de lo contrario, no se opondrá a los encabezados HTTP que faltan.

Pero incluso si obtiene el encabezado de longitud de contenido, must not unreservedly trust it. Los implementadores de servidor también son seres humanos falibles. Tómalo como una respuesta "más probable", valor inicial para un buffer redimensionable. Aún debe estar preparado para manejar menos y más (el peor de los casos).

+7

Eso es muy engañoso. Si la respuesta tiene un campo de encabezado de longitud de contenido y no utiliza codificación fragmentada, esa es la información * solo * que tiene. Si recibe menos contenido, el contenido debe considerarse truncado. Si recibes más contenido, el seridor se rompe, o ya estás viendo la próxima respuesta. –

+0

Estoy humildemente pidiendo una explicación sobre cómo leer la siguiente respuesta podría suceder en un único socket único, cuando el cliente no terminó de analizar el actual, por lo que es muy poco probable que haya enviado la próxima solicitud. Puedo entender mejor el voto negativo. De lo contrario, no veo ningún desacuerdo significativo sobre el asunto. ¿Qué harías cuando leas la longitud del contenido declarado y la lectura del socket te dice que quedan 2 bytes más? En realidad, decir "servidor roto estúpido, no voy a hablar contigo nunca más" no es aplicable tan a menudo como a los buenos programadores les gustaría. –

+0

vtmarvin: el cliente podría usar la canalización. –

Cuestiones relacionadas