http spec はHEAD
リクエストについて述べています:
HEADメソッドは、サーバーが応答でメッセージ本文を返してはならないことを除いて、GETと同じです。 HEAD要求への応答でHTTPヘッダーに含まれるメタ情報は、GET要求への応答で送信された情報と同一である必要があります。
HEAD
リクエストへの応答にContent-Length
ヘッダーを含める必要がありますか?応答本文がない場合でも、GET
要求で返される値にする必要がありますか?または、Content-Lengthを0にする必要がありますか?
私には HTTP 1.1 RFC がかなり具体的であるように見えます:
Content-Lengthエンティティヘッダーフィールドは、受信者に送信されるOCTETの10進数でエンティティボディのサイズを示すか、HEADの場合は =メソッド、リクエストがGETであった場合に送信されるエンティティ本体のサイズ。
HTTP/1.1のセクション14.1 仕様はContent-Lengthヘッダーの詳細を説明し、次のように述べています。
セクション4.4のルールで禁止されていない限り、アプリケーションはこのフィールドを使用してメッセージ本文の転送長を示す必要があります。
「SHOULD」という言葉には、 RFCでの非常に具体的な意味 があります。
- この言葉、または「推奨」という形容詞は、特定の状況において特定の項目を無視する正当な理由が存在する可能性があることを意味しますが、別のコースを選択する前に完全な意味を理解し、慎重に検討する必要があります。
そのため、Content-Lengthが常に表示されるとは限りません。通常、動的に生成されるコンテンツについては、探索的なHEADリクエストを処理するには高すぎる可能性があります。たとえば、a HEAD Apacheへの静的ファイルのリクエストwillにはContent-Lengthがありますが、PHPスクリプトにはない場合があります。
たとえば、このウェブサイトを試してみてください...
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
コンテンツの長さはありません。
はい、HEAD
応答のContent-Length
[〜#〜] should [〜#〜]ですが、常にではありません( @ Paulの答え を参照)GET
応答のContent-Length
値を含めます:
スタックオーバーフローは:
> 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はしません:
> 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
W3CのHTTP-spec 状態:
キャッシュされたエンティティが現在のエンティティと異なることを新しいフィールド値が示す場合(Content-Lengthの変更によって示されるように...).
これは(私にとって)GET
応答の場合と同じように「正しい」値を保持する必要があることを意味します。
受け入れられた答えとは対照的に、 RFC 7231のセクション4.3.2 状態:
サーバーは、HEADリクエストに対する応答として、リクエストがGETであった場合に送信するのと同じヘッダーフィールドを送信する必要があります。ただし、ペイロードヘッダーフィールド(セクション3.3)
—つまり、Content-Length、Content-Range、Trailer、およびTransfer-Encoding—
省略できます。
これは、 Paul Dixon's answer のSHOULDに関するメモよりも さらに弱い です。
- この言葉、または形容詞「オプション」は、アイテムが本当にオプションであることを意味します。あるベンダーは、特定の市場がそれを必要としているため、または別のベンダーが同じアイテムを省略している間に製品を強化していると感じているため、アイテムを含めることを選択できます。
したがって、本当の答えは、Content-Lengthを含める必要はありませんが、含める場合は、正しい値を指定する必要があります。