(fragmentada) HTTP cuerpo del mensaje binario y CRLFs

Me parece que no puede obtener una respuesta definitiva sobre la siguiente pregunta (buscar en Google su mayoría y la lectura de HTTP/1.1 espec):(fragmentada) HTTP cuerpo del mensaje binario y CRLFs

Cuando 'fragmentada' se utiliza la codificación de transferencia, ¿por qué el servidor necesita escribir AMBOS el tamaño del fragmento en bytes y los datos posteriores del fragmento terminan con CRLF. ¿Esto no hace que el envío de datos binarios "CRLF-unclean" y el método sea un poco redundante? ¿Qué pasa si los datos tienen un 0x0A seguido de 0x0D en algún lugar (es decir, estos son en realidad parte de los datos)? ¿Se espera que el cliente se adhiera al tamaño del fragmento explícitamente provisto a la cabeza del trozo o estrangulador en el primer CRLF que encuentra en los datos? Mi comprensión hasta ahora es simplemente tomar el tamaño de porción proporcionado por el servidor, pasar a la siguiente línea, luego leer exactamente esta cantidad de bytes dentro de los siguientes datos (CRLF o sin CRLF adentro), luego omitir ese CRLF que sigue a los datos y repite el procedimiento hasta que no queden más trozos ... ¿Estoy en lo cierto? ¿Cuál es el punto del CRLF después de cada datachunk entonces? ¿Legibilidad?

Fuente

2010-01-24 amn

Un consumidor fragmentada no analiza el cuerpo del mensaje para un par CRLF . Primero lee el número especificado de bytes, y luego lee dos bytes más para confirmar que son CR y LF. Si no lo están, el cuerpo del mensaje está mal formado, y el tamaño se ha especificado incorrectamente o los datos se han corrompido.

El CRLF de arrastre es un aseguramiento de correa y tirantes (por RFC 2616 section 3.6.1, fragmentada de transferencia de codificación), sino que también sirve para mantener constante la regla de que los campos comienzan al principio de la línea.

Fuente

2010-01-24 16:17:16 seh

Gracias por la explicación. ¿Lo tomas del documento RFC 2616, o en otro lugar? ¿Su explicación también implica que el fragmento de respuesta NO PUEDE contener la combinación CRLF como parte de los datos en sí? – amn

Se sigue del EBNF en el RFC; tenga en cuenta que 'chunk-data' consiste en' OCTET', que sugiere que esos bytes no deben interpretarse. Un fragmento de respuesta ciertamente puede contener CRLF. Implementé un códec fragmentado dos veces, ambas veces en Java, y en cada caso no hice ninguna interpretación del contenido de los datos del fragmento. Es opaco para el encuadre del trozo. El decodificador determina la longitud esperada, lee tantos bytes y luego asegura que los siguientes dos bytes son CR y LF. – seh

Eso lo hace perfectamente claro para mí. Regla de los Octetos. Gracias por tu tiempo. – amn

El CRLF después de cada fragmento es probablemente solo para una mejor legibilidad, ya que no es necesario debido al tamaño del fragmento al comienzo de cada fragmento. Pero el CRLF después de la “cabecera trozo” es necesario ya que puede haber información adicional después de que el tamaño del fragmento (ver Chunk Transfer Encoding):

 chunk   = chunk-size [ chunk-extension ] CRLF 
         chunk-data CRLF

Fuente

2010-01-24 16:05:45 Gumbo

Pero, incluso con información adicional, ¿no es redundante proporcionar AMBOS el tamaño de los datos del fragmento Y el CRLF después? Eso era algo de lo que no podía entender, ¿por qué AMBOS? Se toma el tamaño del fragmento, se leen los N bytes especificados más adelante, y eso es para los datos del fragmento real, proceda de allí en adelante para asumir los encabezados del finalizador o un CRLF, sin un CRLF que precede los encabezados opcionales. – amn

Gracias por su tiempo. "seh" ha respondido a mi pregunta, pero, no obstante, toda la información de digerible es valiosa ;-) – amn

(fragmentada) HTTP cuerpo del mensaje binario y CRLFs

Respuesta

Cuestiones relacionadas