[12] HEAD メソッドは、資源のヘッダーのみを返すことを要求するものです。

仕様書

意味

[36] HEAD 要求メソッドは、 GET 要求メソッドが返すであろう応答のヘッダー部のみを返すべきことを示します。

性質

[7] HEAD メソッドは、安全なメソッドで >>6、 冪等なメソッドです >>8。

[10] HEAD は、キャッシュ可能です >>9, >>11。

構文

[14] HEAD 要求の payload の意味は定義されていません >>11。

[15] 実装によっては payload がある要求を拒絶することがあります >>11。

[44] XMLHttpRequest および Request では、要求メッセージの payload body を指定することはできません >>42, >>43。

[16] Content-Length: ヘッダーを指定することができますが、 メッセージ本体の長さではなく、 GET 要求だった場合に含まれるであろう payload body の長さを表します。

Content-Length: を参照。

文脈

[37] Webページの更新チェックを行う利用者エージェントの中には、 HEAD 要求を送信して Last-Modified: の値を調べるものもあります。

[38] Meter によるキャッシュの利用数の計測の仕組みでは、 串から鯖への計測数の報告に HEAD 要求を使うことがあります。

処理

[25] 一般目的の鯖は、 HEAD を実装しなければなりません >>24。

[17] 実際には Web 上で普通に公開されている鯖であっても HEAD に対応しておらず 405 を返すことがあります。 (鯖は実装していて対象資源が実装していないだけだから仕様違反ではない、 とも解釈できるのでしょうか。いずれにせよクライアントは鯖が HEAD に正しく応答することに依存できません。)

[2] HEAD 要求に対する応答は、 メッセージ本体を持ちません >>5, >>11。

[3] Content-Length: や Transfer-Encoding: や表現メタデータを含んでいることもありますが、これらは GET 要求だったとした場合の値であって、 HEAD に対する応答の値ではありません。

[48] HEAD 要求に対する応答が HTTP/0.9 の場合、 Chrome も Firefox も IE もメッセージ本体が存在するものとして扱います。

[13] 鯖は、 GET 要求だったとした場合に送られるのと同じヘッダーを応答に含めて送信するべきです。 ただし、 payload header は、省略して構いません。 >>11

[41] WebDAV コレクションの場合でも、通常の資源と同じように処理することになっています >>40。

[18] GET への応答のキャッシュを HEAD への応答のために用いることもできます。

[28] キャッシュが HEAD 要求に対して 200 応答を受信した場合は、次のようにするべきです >>27。

  1. [29] 相当する GET 要求に対する蓄積された応答を選択します。
  2. [32] 各応答について、
    1. [30] 検証子が新しい応答と一致するもので、 Content-Length: ヘッダーが新しい応答一致するもの (またはどちらも同ヘッダーがない場合) について、
      1. [33] 蓄積された応答から警告符号 1xx の Warning: ヘッダーがあれば削除します。
      2. [34] 304 応答に含まれるWarning: 以外のヘッダーについて、 蓄積された応答の対応するヘッダーを置き換えます。
        • [35] ただし Cache-Control: で制限されている場合を除きます。
    2. [31] それ以外の場合、蓄積された応答を腐敗とします。

歴史

[4] RFC 1945 (HTTP/1.0) 8.2; RFC 2068 (HTTP/1.1) 9.4 HEAD

The HEAD method is identical to GET except that the server must not MUST NOT return any Entity-Body a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request should SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the resource identified entity implied by the Request-URI request without transferring the Entity-Body entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

HEAD 方式は、サーバーが応答中で message-body を返してはならない点を除いて、 GET と同じです。 HEAD 要求に対する応答の HTTP 頭並びに含まれるメタ情報は、 GET 要求に対する応答で送られる情報と同じであるべきです。 この方式は、要求で暗示した実体についてのメタ情報を entity-body 自体を転送せずに得ることができます。 この方式はしばしばハイパーテキスト・リンクの妥当性, 接続可能性, 最近の修正の検査のために使われます。

There is no "conditional HEAD" request analogous to the conditional GET. If an If-Modified-Since header field is included with a HEAD request, it should be ignored.

条件付 GET に対応する「条件付 HEAD」はありません。 If-Modified-Since 頭欄が HEAD 要求に含まれていても、無視するべきです。

The response to a HEAD request may MAY be cacheable in the sense that the information contained in the response may MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

HEAD 要求に対する応答は、応答に含まれる情報を以前にその資源からキャッシュした実体を更新するために使っても構わないという意味でキャッシュ可能です。 キャッシュした実体が現在の実体と異なることを新しい欄値が示していたら (Content-Length, Content-MD5, Content-MD5, ETag または Last-Modified の変更で示される)、 キャッシュはキャッシュ項目を腐敗したものとして扱わなければなりません。

実装

[19] HEAD は、リンク先の存在確認や更新チェックなどの目的で使われることがあります。

[20] HEAD は、本体が必要ない時に鯖の負荷の削減やネットワーク帯域の節約のために用いられることがあります。 ただし、鯖で動的に生成される資源が多いこんにち、 HEAD を用いることが負荷削減につながるかは怪しいところです。アプリケーションによっては HEAD を直接実装せずに、 GET と同様の処理をした結果から本体を除去して返すこともよくあります。

[21] 仕様上は HEAD は実装しなければならないことになっていますが、 実際上は必ずしも実装されていません。実装されていたとしても、 GET の場合と異なる結果を返すことがあります。

[22] そのため、 HEAD のみで十分な情報が得られる場合であっても、 GET を使うこともあります。

[23] 例えば HTML の title を取得したい場合のように、 HEAD では十分な情報が得られず、 GET と範囲要求を用いた方が良いことも多々あります。

[26] tus resumable upload protocol ( ( 版)) http://tus.io/protocols/resumable-upload.html#5-3-1

[406] wget –spider = Head Request : alexking.org ( ( 版)) http://alexking.org/blog/2005/03/11/wget-spider-head-request

[52] ChromeDriver は HEAD を実装していないようで、 GET と同じように応答します。

関連

[39] HEAD 要求は条件付き要求とすることができます。 そのような要求を条件付きHEADと呼ぶことがあります。

[46] Fix #44 in a better way. (Avoid "extracting" undefined.) · whatwg/fetch@b33de72 ( 版) https://github.com/whatwg/fetch/commit/b33de725823d1a2ab99708b717e83112e4ebeb6b

[47] Also throw when new Request() is passed a Request instance with a non-nu... · whatwg/fetch@5be0642 ( 版) https://github.com/whatwg/fetch/commit/5be0642d1ad5b93ed8467ea9acc28f5786981599

[49] No longer include Content-Length for HEAD requests (annevk著, ) https://github.com/whatwg/fetch/commit/674b4d3f9606b22993bc61e135f2739b668c85a1

[50] Webmention () https://webmention.net/draft/#h-sender-discovers-receiver-webmention-endpoint

Senders may initially make an HTTP HEAD request [RFC7231] to check for the Link header before making a GET request.

[51] Webmention () https://webmention.net/draft/#h-limits-on-get-requests

Receivers may make an initial HTTP HEAD request when verifying the link and decide whether to make a full GET request after initially inspecting the content type, length, or other HTTP headers returned.

[53] Expose Content-Length header in CORS requests · Issue #622 · whatwg/fetch () https://github.com/whatwg/fetch/issues/622

[54] Preserve HEAD method on 303 redirect (annevk著, ) https://github.com/whatwg/fetch/commit/6f29b764cc57aaf2f431e15a3f0fec029926e9e0

[55] 303 redirects should preserve HEAD · Issue #753 · whatwg/fetch () https://github.com/whatwg/fetch/issues/753

[56] Preserve HEAD method on 303 redirect by annevk · Pull Request #796 · whatwg/fetch () https://github.com/whatwg/fetch/pull/796