メインコンテンツへスキップ
Toolsbase Logo

HTTPヘッダーリファレンス

よく使うHTTPヘッダーをカテゴリ別にまとめたリファレンス。リクエスト・レスポンス・キャッシュ・セキュリティ・CORSヘッダーの構文と使用例を検索・コピーできます。

使い方使い方を開く
  1. 1

    ヘッダーを検索・フィルター

    検索欄にヘッダー名を入力するか、カテゴリ(リクエスト、レスポンスなど)でフィルタリングして目的のヘッダーを見つけます。

  2. 2

    構文と使用例を確認

    各ヘッダーの説明、構文フォーマット、実際の使用例を確認します。

  3. 3

    ヘッダー名をコピー

    コピーアイコンをクリックしてヘッダー名をクリップボードにコピーし、すぐに使用できます。

Content-Type
リソースまたはリクエストボディのメディアタイプを示す

構文

Content-Type: <media-type>[; charset=<charset>][; boundary=<boundary>]

使用例

Content-Type: application/json
JSONのリクエスト・レスポンスボディ
Content-Type: text/html; charset=utf-8
UTF-8エンコードのHTMLドキュメント
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
ファイルアップロードのフォームデータ

Content-Length
メッセージボディのバイト数を示す

構文

Content-Length: <length>

使用例

Content-Length: 348
レスポンスボディが348バイト
Content-Length: 0
ボディなし(DELETEレスポンスなど)

Date
メッセージが生成された日時を示す

構文

Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

使用例

Date: Wed, 21 Oct 2015 07:28:00 GMT
レスポンスのタイムスタンプ

Connection
現在のトランザクション後にネットワーク接続を維持するかどうかを制御する

構文

Connection: keep-alive | close

使用例

Connection: keep-alive
後続リクエストのために接続を維持
Connection: close
レスポンス後に接続を閉じる

Accept
クライアントが処理できるデータ形式をサーバーに通知する

構文

Accept: <MIME_type>/<MIME_subtype>[;q=<weight>], ...

使用例

Accept: application/json
JSONレスポンスのみ受け入れる
Accept: text/html, application/xhtml+xml, */*;q=0.8
HTMLを優先し、何でも受け入れる
Accept: image/webp, image/png, */*
WebP画像を優先し、次にPNG

Authorization
クライアントがサーバーに認証するための資格情報を含む

構文

Authorization: <auth-scheme> <credentials>

使用例

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
JWT Bearerトークン認証
Authorization: Basic dXNlcjpwYXNzd29yZA==
HTTP Basic認証(Base64エンコード)
Authorization: ApiKey my-api-key-here
カスタムAPIキー認証

Cookie
Set-Cookieでサーバーが送信したHTTPクッキーを含む

構文

Cookie: <cookie-list>

使用例

Cookie: session_id=abc123
単一のセッションクッキー
Cookie: theme=dark; lang=ja; session=xyz
複数のクッキーを1つのヘッダーで送信

User-Agent
ブラウザとOSを識別する文字列

構文

User-Agent: <product>/<version> (<system-info>) <extensions>

使用例

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Windows 10のChrome
User-Agent: curl/7.68.0
curl HTTPクライアント

Referer
現在のリクエストが行われた前のページのURLを含む

構文

Referer: <url>

使用例

Referer: https://example.com/page1
このページから遷移してきた
Referer: https://www.google.com/search?q=example
検索エンジンから来訪

Host
リクエストの送信先サーバーのホスト名とポート番号を指定する

構文

Host: <host>[:<port>]

使用例

Host: example.com
標準ホスト名(ポート80/443は省略)
Host: api.example.com:8080
非標準ポートを含むホスト名

Set-Cookie
サーバーからクライアントへクッキーを送信して保存させる

構文

Set-Cookie: <cookie-name>=<cookie-value>[; <attributes>]

使用例

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict
セキュアなセッションクッキー
Set-Cookie: theme=dark; Max-Age=31536000; Path=/
1年間有効な設定クッキー
Set-Cookie: token=xyz; Domain=.example.com; Secure
ドメイン全体に有効なセキュアクッキー

Location
リダイレクト時にクライアントを誘導するURLを示す

構文

Location: <url>

使用例

Location: https://example.com/new-page
絶対URLへのリダイレクト(301/302)
Location: /dashboard
ログイン後の相対パスリダイレクト

Server
リクエストを処理したオリジンサーバーのソフトウェアを説明する

構文

Server: <product>

使用例

Server: nginx/1.18.0
nginxウェブサーバーのバージョン
Server: Apache/2.4.41 (Ubuntu)
Ubuntu上のApacheウェブサーバー

WWW-Authenticate
リソースへのアクセスに使用する認証方法を定義する

構文

WWW-Authenticate: <type> realm=<realm>[, <params>]

使用例

WWW-Authenticate: Basic realm="My Site"
HTTP Basic認証のプロンプト
WWW-Authenticate: Bearer realm="api", error="invalid_token"
エラー付きBearerトークン認証

Cache-Control
リクエストとレスポンス両方のキャッシュメカニズムに対するディレクティブ

構文

Cache-Control: <directive>[, <directive>]...

使用例

Cache-Control: no-cache, no-store, must-revalidate
キャッシュを完全に無効化
Cache-Control: public, max-age=31536000
1年間パブリックキャッシュ(静的アセット向け)
Cache-Control: private, max-age=600
10分間プライベートキャッシュ

ETag
リソースの特定バージョンを示す識別子。キャッシュ検証に使用される

構文

ETag: [W/]"<etag_value>"

使用例

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
強いETag(完全一致が必要)
ETag: W/"0815"
弱いETag(意味的に同等)

If-None-Match
指定されたETagにリソースが一致しない場合にのみリクエストを実行する条件付きリクエスト

構文

If-None-Match: [W/]"<etag_value>"[, [W/]"<etag_value>"]*

使用例

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETagが一致すれば304を返す(キャッシュヒット)
If-None-Match: *
既存リソースが存在しない場合のみ成功

Expires
レスポンスが陳腐化する日時を指定する

構文

Expires: <http-date>

使用例

Expires: Wed, 21 Oct 2025 07:28:00 GMT
この日時にキャッシュが期限切れ
Expires: 0
すでに期限切れ(キャッシュなし)

Last-Modified
サーバー上でリソースが最後に変更された日時

構文

Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

使用例

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
ファイルが最後に変更された日時

Content-Security-Policy
ページで読み込めるリソースをブラウザが制御するためのポリシーを指定する

構文

Content-Security-Policy: <policy-directive>; ...

使用例

Content-Security-Policy: default-src 'self'
同一オリジンのリソースのみ許可
Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com
自身とCDNからのスクリプトを許可
Content-Security-Policy: default-src 'none'; img-src 'self' data:; style-src 'self'
自身の画像とスタイルのみを許可する厳格なポリシー

X-Frame-Options
ブラウザがページをフレーム内に表示することを許可するかどうかを示す

構文

X-Frame-Options: DENY | SAMEORIGIN

使用例

X-Frame-Options: DENY
フレーム内表示を完全に禁止(クリックジャッキング対策)
X-Frame-Options: SAMEORIGIN
同一オリジンからのフレーム内表示のみ許可

Strict-Transport-Security
ブラウザに指定期間HTTPSでの接続を強制する

構文

Strict-Transport-Security: max-age=<expire-time>[; includeSubDomains][; preload]

使用例

Strict-Transport-Security: max-age=31536000
1年間HTTPSを強制
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
2年間、サブドメイン含む、HSTSプリロード対象

X-Content-Type-Options
宣言されたContent-Typeを尊重させてMIMEタイプスニッフィングを防ぐ

構文

X-Content-Type-Options: nosniff

使用例

X-Content-Type-Options: nosniff
MIMEタイプスニッフィングを無効化

X-XSS-Protection
旧式ブラウザでXSSフィルタリングを有効にする(現在はCSPに置き換えられつつある)

構文

X-XSS-Protection: 0 | 1[; mode=block | report=<reporting-uri>]

使用例

X-XSS-Protection: 1; mode=block
XSSフィルターを有効にし、攻撃検出時はページをブロック
X-XSS-Protection: 0
XSSフィルターを無効化(厳格なCSPと併用)

Permissions-Policy
ドキュメントで使用できるブラウザ機能とAPIを制御する

構文

Permissions-Policy: <feature>=(<allowlist>)[, ...]

使用例

Permissions-Policy: camera=(), microphone=(), geolocation=()
カメラ・マイク・位置情報を無効化
Permissions-Policy: geolocation=(self "https://trusted.example.com")
自身と信頼されたオリジンからの位置情報を許可

Access-Control-Allow-Origin
クロスオリジンリクエストでリソースへのアクセスを許可するオリジンを示す

構文

Access-Control-Allow-Origin: * | <origin>

使用例

Access-Control-Allow-Origin: *
すべてのオリジンを許可(パブリックAPI)
Access-Control-Allow-Origin: https://example.com
特定のオリジンのみ許可

Access-Control-Allow-Methods
CORSプリフライトレスポンスでリソースへのアクセスに許可するHTTPメソッドを指定する

構文

Access-Control-Allow-Methods: <method>[, <method>]*

使用例

Access-Control-Allow-Methods: GET, POST, OPTIONS
GET、POST、プリフライトOPTIONSを許可
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
一般的なRESTメソッドをすべて許可

Access-Control-Allow-Headers
実際のCORSリクエストで使用できるHTTPヘッダーを示す

構文

Access-Control-Allow-Headers: <header-name>[, <header-name>]*

使用例

Access-Control-Allow-Headers: Content-Type, Authorization
Content-TypeとAuthorizationヘッダーを許可
Access-Control-Allow-Headers: *
すべてのリクエストヘッダーを許可

Access-Control-Max-Age
プリフライトリクエストの結果をキャッシュできる時間を示す

構文

Access-Control-Max-Age: <delta-seconds>

使用例

Access-Control-Max-Age: 86400
プリフライトレスポンスを1日キャッシュ
Access-Control-Max-Age: 3600
プリフライトレスポンスを1時間キャッシュ

HTTPヘッダーリファレンスとは

HTTPヘッダーリファレンスは、よく使うHTTPリクエスト・レスポンスヘッダーを網羅したチートシートです。汎用・リクエスト・レスポンス・キャッシュ・セキュリティ・CORSの6カテゴリに整理され、各ヘッダーの説明・構文フォーマット・実際の使用例を確認できます。

主な機能

  • 6カテゴリにまたがる29の主要HTTPヘッダーを収録
  • 各ヘッダーの構文フォーマットと使用例
  • カテゴリ別フィルタリング(リクエスト、レスポンス、キャッシュ、セキュリティ、CORS)
  • ヘッダー名や説明文のリアルタイム検索
  • ヘッダー名のワンクリックコピー

こんな場面で役立ちます

  • HTTPヘッダーの正しい構文を確認したいとき
  • セキュリティヘッダー(CSP、HSTS、X-Frame-Options)の実装時
  • クロスオリジンAPIアクセスのためのCORSヘッダー設定時
  • パフォーマンス最適化のためのキャッシュヘッダー設定時
  • バックエンド・フロントエンド開発中のクイックリファレンス

よくある質問

Cache-ControlとExpiresの違いは何ですか?

Cache-Controlはモダンな標準仕様で、両方が存在する場合に優先されます。max-age、no-cache、no-storeなどのディレクティブで細かい制御が可能です。Expiresは絶対日時を指定するレガシーヘッダーですが、HTTP/1.0との互換性のために今でも使われることがあります。

ETagとLast-Modifiedの違いは何ですか?

ETagはコンテンツに基づく不透明な識別子で、Last-Modifiedはタイムスタンプです。ETagの方が信頼性が高く、同じコンテンツのファイルが異なる時刻に再生成された場合でも変化します。Last-Modifiedは1秒の精度しかなく、高頻度な更新を見逃す可能性があります。

なぜサイトにセキュリティヘッダーを追加すべきなのですか?

Content-Security-Policy、X-Frame-Options、Strict-Transport-Securityなどのセキュリティヘッダーは、XSS、クリックジャッキング、プロトコルダウングレード攻撃などの一般的な攻撃から保護します。多層防御セキュリティの重要な一部であり、サーバーやCDNレベルで簡単に追加できます。

CORSのプリフライトリクエストとシンプルリクエストの違いは何ですか?

シンプルリクエスト(標準ヘッダーを使ったGET/POST)は直接送信されます。プリフライトリクエスト(OPTIONS)は、複雑なリクエスト(PUT/DELETE、カスタムヘッダー、特定のContent-Type値を使用するもの)に対してブラウザが自動的に送信し、実際のリクエストを送る前にサーバーがクロスオリジンアクセスを許可しているか確認します。

X-XSS-Protectionは使うべきですか?

X-XSS-Protectionは旧式ブラウザ向けのレガシーヘッダーです。モダンなブラウザはXSS監査機能を非推奨にしています。代わりに厳格なContent-Security-Policyヘッダーを実装してください。強固なCSPを使用する場合は、X-XSS-Protection: 0を設定することが一般的に推奨されています。