encabezados de respuesta HTTP válidos sin codificación de transferencia y longitud de contenido?

Question

¿Es legal un encabezado de respuesta HTTP (como el de abajo) incluso si no contiene Content-Length o Transfer-Encoding?

- Http: Response, HTTP/1.1, Status: Ok, URL: /AAA/B.json 
    ProtocolVersion: HTTP/1.1 
    StatusCode: 200, Ok 
    Reason: OK 
    Expires: Fri, 05 Oct 2012 01:41:30 GMT 
    Date: Fri, 05 Oct 2012 01:40:46 GMT 
    Vary: Accept-Encoding 
    Accept-Ranges: bytes 
    Cache-Control: public, max-age=43 
    Server: Noelios-Restlet-Engine/1.1.10 
    ContentType: application/json;charset=UTF-8 
    ContentEncoding: gzip 
    Connection: close 
    X-Served-By: 85.111 
    HeaderEnd: CRLF 

Esperaba ver Content-Length o Transfer-Encoding, pero ninguno de ellos existe.

He leído el HTTP-RFC pero todavía no estoy seguro.

@CodeCaster, hice la sección 4.4 RFC leer, pero todavía no tengo claro, como se puede ver, la cabecera de respuesta se utiliza para devolver una secuencia de JSON, por lo que:

• sección 4.4, la regla 1 define NO DEBE incluir un cuerpo del mensaje, no parece aplicarse a mi caso.
• sección 4.4, regla 4, no estoy seguro de esto, pero como no veo "multipart/byteranges" en el encabezado de respuesta, ¿significa que esta regla no es aplicable para mí?
• sección 4.4 regla 5, esto no es muy claro para mí ya que el encabezado actual contiene "Conexión: cerrar", ¿está relacionado?

¿Alguna otra pregunta?

Answer 1

Sí, es válido. Existen cinco formas de determinar la longitud del mensaje:

RFC 2616 Section 4.4. Message Length:

La transferencia de longitud de un mensaje es la longitud del mensaje de cuerpo como que aparece en el mensaje; es decir, después de cualquier codificación de transferencia se ha aplicado . Cuando un mensaje de cuerpo está incluido con un mensaje, la transferencia de longitud de ese cuerpo se determina por una de las siguientes (en orden de prioridad):

1. Cualquier mensaje de respuesta que "NO DEBE" incluir un cuerpo de mensaje (como como las respuestas 1xx, 204 y 304 y cualquier respuesta a una solicitud HEAD ) siempre termina con la primera línea vacía después de los campos de encabezado de entidad , independientemente de los campos de encabezado de entidad presentes en mensaje.

2. Si un campo de encabezado Transfer-Encoding (sección 14.41) está presente y tiene cualquier valor distinto de "identidad", entonces la transferencia de longitud es definido por el uso del "fragmentada" (sección de transferencia de codificación de 3,6), a menos que el mensaje finalice cerrando la conexión.

3. Si un campo de cabecera Content-Length (sección 14.13) está presente, su valor decimal en octetos representa tanto la entidad de longitud y la transferencia de longitud . El campo de encabezado Content-Length NO DEBE enviarse si estas dos longitudes son diferentes (es decir, si está presente un campo de encabezado Transfer-Encoding ). Si se recibe un mensaje con un campo de encabezado Transfer-Encoding y un campo de encabezado Content-Length, este último se DEBE ignorar.

4. Si el mensaje utiliza el tipo de medio "multipart/byteranges", y la transferencia de longitud no se especifica lo contrario, entonces este auto tipo de medio que delimitan define la transferencia de longitud. Este tipo de medio [M] UST NO se debe utilizar a menos que el remitente sepa que el destinatario puede analizar ; la presencia en una solicitud de un encabezado Range con múltiples byte- especificadores de rango de un cliente 1.1 implica que el cliente puede analizar respuestas multipart/byteranges.

   Un encabezado de rango puede ser reenviado por un proxy 1.0 que no comprende entender multipart/byteranges; en este caso, el servidor DEBE delimitar el mensaje utilizando los métodos definidos en los puntos 1,3 o 5 de esta sección.

5. Por el servidor que cierra la conexión. (Cierre de la conexión no se puede utilizar para indicar el final de un cuerpo de la petición, ya que dejaría sin posibilidad para el servidor para enviar de vuelta una respuesta.)