headers - php curl http header

¿Cabecera Content-Length con solicitudes HEAD?

Question

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?

Answer 1

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 codificación de transferencia-

PUEDE ser omitido.

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

5. 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.

Answer 2

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 .

Answer 3

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 .

Answer 4

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 :

hace:

> telnet .com 80
HEAD / HTTP/1.1
Host: .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

Answer 5

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 :

3. 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 .com 80
HEAD / HTTP/1.0
Host:.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=..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=..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í.