Cuerpo de mensaje binario HTTP (fragmentado) y CRLFs

Parece que no puedo obtener una respuesta definitiva a la siguiente pregunta (en su mayoría en Google y leyendo las especificaciones de HTTP / 1.1):

Cuando se utiliza la codificación de transferencia "fragmentada", ¿por qué el servidor necesita escribir TANTO el tamaño del fragmento en bytes y hacer que los datos de los fragmentos subsiguientes terminen con CRLF? ¿No hace esto el envío de datos binarios "CRLF-unclean" y el método un poco redundante? ¿Qué sucede 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 trozo proporcionado explícitamente al principio del trozo o estrangulador en el primer CRLF que encuentra en los datos? Mi entendimiento hasta ahora es simplemente tomar el tamaño de trozo proporcionado por el servidor, pasar a la siguiente línea, luego leer exactamente esta cantidad de bytes desde los siguientes datos (CRLF o no CRLF dentro), luego omitir el CRLF que sigue a los datos y repita el procedimiento hasta que no haya más trozos ... ¿Tengo razón? ¿Cuál es el punto de la CRLF después de cada datachunk? ¿Legibilidad?

Respuestas a la pregunta(2)

Su respuesta a la pregunta