¿Cabecera Content-Length con solicitudes HEAD?

La especificación http dice acerca de la solicitud HEAD :

El método HEAD es idéntico a GET, excepto que el servidor NO DEBE devolver un cuerpo del mensaje en la respuesta. La metainformación contenida en los encabezados HTTP en respuesta a una solicitud HEAD DEBERÍA ser idéntica a la información enviada en respuesta a una solicitud GET.

¿La respuesta a una solicitud HEAD contener un encabezado Content-Length ? ¿Debería ser el valor que se devolvería en una solicitud GET , incluso si no hay un cuerpo de respuesta? ¿O debería el Content-Length ser 0?

Para mí, parece que HTTP 1.1 RFC es bastante específico:

El campo Content-Length entity-header indica el tamaño del cuerpo de la entidad, en número decimal de OCTET, enviado al destinatario o, en el caso del método HEAD, el tamaño del cuerpo de la entidad que se habría enviado. la solicitud ha sido un GET .

La sección 14.13 de la especificación HTTP / 1.1 detalla el encabezado Content-Length y dice esto:

Las aplicaciones DEBEN usar este campo para indicar la longitud de transferencia del cuerpo del mensaje, a menos que esto esté prohibido por las reglas de la sección 4.4.

La palabra “DEBERÍA” tiene un significado muy específico en las RFC :

  1. DEBERÍA Esta palabra, o el adjetivo “RECOMENDADO”, significa que puede haber razones válidas en circunstancias particulares para ignorar un artículo en particular, pero las implicaciones completas deben ser entendidas y sopesadas cuidadosamente antes de elegir un curso diferente.

Por lo tanto, es posible que no siempre vea una longitud de contenido. Por lo general, es posible que no lo vea para ningún contenido que se genere dinámicamente, ya que puede ser demasiado caro para atender una solicitud de HEAD exploratoria. Por ejemplo, una solicitud HEAD a Apache para un archivo estático tendrá una longitud de contenido, pero una solicitud de un script PHP no.

Por ejemplo, prueba este mismo sitio web …

 telnet stackoverflow.com 80 HEAD / HTTP/1.0 Host:stackoverflow.com HTTP/1.1 200 OK Date: Mon, 11 Jan 2016 10:58:25 GMT Content-Type: text/html; charset=utf-8 Connection: close Set-Cookie: __cfduid=c2eb4742a1e02d89cab0402220736c0bd1452509905; expires=Tue, 10-Jan-17 10:58:25 GMT; path=/; domain=.stackoverflow.com; HttpOnly Cache-Control: public, no-cache="Set-Cookie", max-age=36 Expires: Mon, 11 Jan 2016 10:59:02 GMT Last-Modified: Mon, 11 Jan 2016 10:58:02 GMT Vary: * X-Frame-Options: SAMEORIGIN X-Request-Guid: 487e80bc-3783-4cfd-d883-a3bc84253234 Set-Cookie: prov=8dc24306-c067-45eb-bf5d-cffa855c2b03; domain=.stackoverflow.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly Server: cloudflare-nginx CF-RAY: 26303c15f8e035a2-LHR 

No hay contenido de longitud allí.

Sí, la Content-Length del Content-Length de una respuesta HEAD DEBE , pero no siempre lo hace (ver la respuesta de @ Paul ) incluir el valor de Content-Length del Content-Length de una respuesta GET :

Stack Overflow hace:

 > telnet stackoverflow.com 80 HEAD / HTTP/1.1 Host: stackoverflow.com HTTP/1.1 200 OK Cache-Control: public, max-age=60 Content-Length: 362245 < -------- Content-Type: text/html; charset=utf-8 Expires: Mon, 04 Oct 2010 11:51:49 GMT Last-Modified: Mon, 04 Oct 2010 11:50:49 GMT Vary: * Date: Mon, 04 Oct 2010 11:50:49 GMT 

Google no:

 > telnet www.google.com 80 HEAD / HTTP/1.1 Host: www.google.ie HTTP/1.1 200 OK Date: Mon, 04 Oct 2010 11:55:36 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 Server: gws X-XSS-Protection: 1; mode=block Transfer-Encoding: chunked 

La especificación HTTP en W3C establece:

Si los nuevos valores de campo indican que la entidad en caché difiere de la entidad actual (como lo indicaría un cambio en Content-Length, …

Lo cual (para mí) significa que debe contener el valor “correcto” como lo haría en una respuesta GET .

Contra la respuesta aceptada, la sección 4.3.2 de RFC 7231 establece:

El servidor DEBERÍA enviar los mismos campos de encabezado en respuesta a una solicitud HEAD que hubiera enviado si la solicitud hubiera sido un GET, excepto que los campos del encabezado de la carga útil (Sección 3.3)

-Lo que equivale a decir, contenido-longitud, rango de contenido, avance y encoding de transferencia-

PUEDE ser omitido.

Esto es incluso más débil que la nota de SHOULD en la respuesta de Paul Dixon :

  1. MAYO Esta palabra, o el adjetivo “OPCIONAL”, significa que un artículo es verdaderamente opcional. Un vendedor puede optar por incluir el artículo porque un mercado en particular lo requiere o porque el vendedor siente que mejora el producto, mientras que otro proveedor puede omitir el mismo artículo.

Entonces, la verdadera respuesta es que no necesita incluir Content-Length, pero si lo hace, debe dar el valor correcto.