HEAD

使い方

HEAD リクエストは、リソースに関するメタデータ（サイズ、種類、鮮度、存在）を取得します。サーバーは GET とまったく同じようにリクエストを処理しますが、ボディを送信する直前で停止します。Content-Length や Content-Type を含むすべてのレスポンスヘッダーは、完全な GET レスポンスのものと一致します。

一般的なユースケース

リンクの検証。自動化ツールは、ページ全体をダウンロードせずに URL が 200 を返すかを確認するために HEAD リクエストを送信します。リンク切れは 404 や 410 レスポンスとして現れます。

監視とヘルスチェック。アップタイムモニターは HEAD でエンドポイントを調べ、可用性を確認します。レスポンスサイズが小さいため帯域が節約され、ポーリング間隔を短縮できます。

コンテントネゴシエーションの事前確認。クライアントは、完全なリソースを取得するかどうかを判断する前に Content-Type、Content-Encoding、Content-Language の各ヘッダーを調べます。

キャッシュの検証。ETag や Last-Modified を伴う HEAD レスポンスにより、キャッシュはボディをダウンロードせずに鮮度を確認できます。HEAD レスポンスのヘッダーがキャッシュ済みのコピーは古いと示している場合、キャッシュはそのエントリをそのようにマークします。

ダウンロードサイズの推定。ファイルマネージャーやダウンロードツールは、転送を開始する前にファイルサイズを表示したりディスク領域を確保したりするため、HEAD レスポンスから Content-Length を読み取ります。

注意

HEAD リクエストのリクエストボディには、一般的に定義されたセマンティクスがありません。一部の実装はボディを伴う HEAD リクエストを拒否します。ボディを含めると、メッセージのフレーミングを誤って解析する中間装置でリクエストスマグリングの脆弱性を誘発するリスクがあります。

例

リソースが存在するかを確認し、レスポンスヘッダーを調べるための HEAD リクエストです。サーバーはコンテンツのメタデータとともに 200 を返しますが、ボディはありません。

リクエスト

HEAD /report.pdf HTTP/1.1
Host: example.com

レスポンス

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 284750
Last-Modified: Mon, 10 Feb 2025 08:30:00 GMT
ETag: "f47ac10b"

Content-Length ヘッダーから、そのファイルがおよそ 278 KB であることがわかります。Last-Modified と ETag の各ヘッダーは、以降の取得における条件付きリクエストのためのバリデーターを提供します。

CORS

HEAD は CORS セーフリストメソッドです。クロスオリジンの HEAD リクエストはプリフライトリクエストを発生させず、GET と同じセーフリストの挙動に従います。

HEAD と GET の比較

HEAD は GET と同じヘッダーを返しますが、レスポンスボディは完全に省略します。そのため HEAD は、メタデータのみを必要とするタスクにおいてより高速で帯域効率に優れます。

一般的な用途としては、リソースが存在するかの確認、ファイルサイズを知るための Content-Length の読み取り、Last-Modified 日時の調査、完全なリソースをダウンロードせずに ETag などのキャッシュバリデーターを取得することが挙げられます。

一部のサーバーは、内部的に完全な GET ハンドラーを実行してからレスポンス送信前にボディを取り除くことで HEAD を実装しています。その場合、パフォーマンス上の利点はボディのバイト列の転送時間を節約できる分に限られます。

HEAD レスポンスはキャッシュ済みの GET レスポンスも更新します。キャッシュが HEAD リクエストを送信し、返されたバリデーターが保存済みの GET エントリと一致する場合、キャッシュは保存されたヘッダーをそれに応じて更新します。

SEO への影響

検索クローラーはページを HEAD ではなく GET で取得するため、HEAD はインデックス登録を促進しません。HEAD は、ボディをダウンロードせずに URL が 200 を返すことを確認するリンクチェッカー、アップタイムモニター、SEO 監査ツールにとっては引き続き有用です。