web-dev-qa-db-fra.com

En-tête Content-Length avec HEAD requêtes?

http spec dit à propos de la demande HEAD:

La méthode HEAD est identique à GET sauf que le serveur NE DOIT PAS retourner de corps de message dans la réponse. La métainformation contenue dans les en-têtes HTTP en réponse à une demande HEAD DEVRAIT être identique aux informations envoyées en réponse à une demande GET.

La réponse à une demande HEAD doit-elle contenir un en-tête Content-Length? Doit-il être la valeur qui serait retournée sur une demande GET, même s'il n'y a pas de corps de réponse? Ou la longueur du contenu doit-elle être 0?

httpresthttp-headers
61
deamon

Pour moi, il semble que le HTTP 1.1 RFC est assez spécifique:

Le champ d'en-tête d'entité Content-Length indique la taille du corps d'entité, en nombre décimal d'OCTET, envoyé au destinataire ou, dans le cas de HEAD, la taille du corps d'entité qui aurait été envoyé si la demande avait été un GET .

42
nietaki

Section 14.13 du HTTP/1.1 spéc a détaillé l'en-tête Content-Length, et dit ceci:

Les applications DEVRAIENT utiliser ce champ pour indiquer la longueur de transfert du corps du message, sauf si cela est interdit par les règles de la section 4.4.

Le mot 'DEVRAIT' a un sens très spécifique dans les RFC :

  1. DEVRAIT Ce mot, ou l'adjectif "RECOMMANDÉ", signifie qu'il peut exister des raisons valables dans des circonstances particulières d'ignorer un élément particulier, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir un cours différent.

Ainsi, vous ne verrez pas toujours une longueur de contenu. En règle générale, il se peut que vous ne le voyiez pas pour tout contenu généré dynamiquement, car cela pourrait être trop coûteux pour traiter une demande exploratoire HEAD. Par exemple, une HEAD demande à Apache pour un fichier statique aura un Content-Length, mais une demande pour un script PHP .

Par exemple, essayez ce site Web même ...

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

Aucune longueur de contenu là-bas.

42
Paul Dixon

Oui le Content-Length d'une réponse HEAD [~ # ~] devrait [~ # ~] , mais pas toujours (voir @ Réponse de Paul ) inclure le Content-Length valeur d'une réponse GET:

Le débordement de pile:

> 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 ne:

> 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
13
Daniel Vassallo

spécification HTTP au W3C indique:

Si les nouvelles valeurs de champ indiquent que l'entité mise en cache diffère de l'entité actuelle (comme cela serait indiqué par un changement de Content-Length, ...

Ce qui (pour moi) signifie qu'il devrait contenir la valeur "correcte" comme vous le feriez dans une réponse GET.

8
Michael Banzon

Contra la réponse acceptée, section 4.3.2 de la RFC 7231 indique:

Le serveur DEVRAIT envoyer les mêmes champs d'en-tête en réponse à une demande HEAD comme il l'aurait envoyé si la demande avait été un GET, sauf que les champs d'en-tête de charge utile (Section 3.3)

—C'est-à-dire, Content-Length, Content-Range, Trailer et Transfer-Encoding—

PEUT être omis.

C'est encore plus faible que la note sur DEVRAIT dans réponse de Paul Dixon :

  1. MAI Ce mot, ou l'adjectif "FACULTATIF", signifie qu'un élément est vraiment facultatif. Un fournisseur peut choisir d'inclure l'article parce qu'un marché particulier l'exige ou parce que le vendeur estime qu'il améliore le produit tandis qu'un autre fournisseur peut omettre le même article.

La vraie réponse est donc que vous n'avez pas besoin d'inclure Content-Length, mais si vous le faites, vous devez donner la valeur correcte.

5
David Moles