ヘッダー

静的アセットを配信するとき、Workers はデフォルトでレスポンスにいくつかのヘッダーを付けます。次のとおりです。

• Content-Type

  アセットのアップロード処理 で値が渡された場合、レスポンスに Content-Type ヘッダーが付きます。Wrangler は、ファイル拡張子から MIME タイプを自動判定します。

• Cache-Control: public, max-age=0, must-revalidate

  リクエストに Authorization または Range ヘッダーがないときに送られます。このレスポンスヘッダーは、アセットをキャッシュしてよいが、使う前に毎回鮮度を再検証するようブラウザーに伝えます。このデフォルトにより、静的ページの性能を保ちつつ、古いコンテンツが配信されないようにします。

• ETag

  デフォルトの Cache-Control ヘッダーを補完します。値は静的アセットファイルのハッシュです。ブラウザーは後続リクエストで If-None-Match ヘッダーに使い、一致した場合はファイル全体を再ダウンロードせずに鮮度を確認できます。

• CF-Cache-Status

  アセットがキャッシュから配信されたか（HIT）否か（MISS）を示します。¹

Cloudflare は、性能向上や Worker アプリケーションのセキュリティ強化のため、静的アセットのレスポンスに新しいヘッダーをいつでも追加する権利を留保します。

静的アセットのレスポンスに付くデフォルトのレスポンスヘッダーは、上書き、削除、追加ができます。プロジェクトの静的アセットディレクトリに、拡張子なしのプレーンテキストファイル _headers を作成します。このファイル自体は静的アセットとして配信されません。Workers が解析し、そのルールを静的アセットのレスポンスに適用します。

フレームワークを使っている場合、public/ や static/ という名前のディレクトリがあることが多く、ここには favicon、robots.txt、サイトマニフェストなど、デプロイ可能なアセットが入っています。これらのファイルはビルド時に最終出力ディレクトリへコピーされるため、_headers ファイルを置く場所として適しています。フレームワークを使っていない場合は、_headers ファイルを 静的アセットディレクトリ に直接置けます。

_headers ファイルで定義したヘッダーは、Cloudflare が通常送るヘッダーより優先されます。

ヘッダールールは複数行のブロックで定義します。ブロックの 1 行目は、ルールのヘッダーを適用する URL または URL パターンです。次の行に、ヘッダー名とヘッダー値のインデント付きリストを書きます。

[url]
  [name]: [value]

絶対 URL も使えます。ただし、絶対 URL は https で始める必要があり、ポートの指定はできません。_headers のルールは、受信リクエストとの照合時にポートとプロトコルを無視します。たとえば https://example.com/path のようなルールは、other://example.com:1234/path へのリクエストにも一致します。

続く行に [name]: [value] のペアを必要なだけ定義できます。例:

# This is a comment
/secure/page
	X-Frame-Options: DENY
	X-Content-Type-Options: nosniff
	Referrer-Policy: no-referrer

/static/*
	Access-Control-Allow-Origin: *
	X-Robots-Tag: nosnippet

https://myworker.mysubdomain.workers.dev/*
	X-Robots-Tag: noindex

複数ルールの URL パターンに一致する受信リクエストは、該当ルールすべてのヘッダーを継承します。前の _headers ファイルでは、次のリクエストに次のヘッダーが適用されます。

ヘッダールールは最大 100 件まで定義できます。_headers ファイルの各行は 2,000 文字制限です。空白、ヘッダー名、値を含む行全体がこの制限に含まれます。

_headers ファイルで同じヘッダーが 2 回適用されると、値はカンマ区切りで結合されます。

デフォルトヘッダーや、より広い範囲のルールで追加されたヘッダーを外したい場合があります。ヘッダー名の先頭に感嘆符とスペース（! ）を付けます。

/*
  Content-Security-Policy: default-src 'self';

/*.jpg
  ! Content-Security-Policy

_redirects と同じ URL 一致機能を、_headers ファイルでも使えます。ただし、リダイレクトはヘッダーより先に適用されます。リクエストがリダイレクトとヘッダーの両方に一致する場合は、リダイレクトが優先されます。

一致時、アスタリスク（*）で表すスプラットパターンは、すべての文字に貪欲に一致します。URL に含められるスプラットは 1 つだけです。

一致した値は、ヘッダー値の中で :splat プレースホルダーとして参照できます。

プレースホルダーは :placeholder_name で定義できます。コロン（:）のあとに英字が続くとプレースホルダーの開始です。続くプレースホルダー名は英数字とアンダースコアで構成します（:[A-Za-z]\w*）。名前付きプレースホルダーは、それぞれ 1 回だけ参照できます。プレースホルダーは区切り文字以外のすべての文字に一致します。ホストの一部である場合、区切り文字はピリオド（.）またはスラッシュ（/）です。パスの一部である場合は、スラッシュ（/）のみです。

同様に、一致した値は :placeholder_name を使い、header の値でも利用できます。

/movies/:title
  x-movie-name: You are watching ":title"

ほかのドメインが Worker のすべての静的アセットを取得できるようにするには、_headers ファイルに次を追加します。

/*
  Access-Control-Allow-Origin: *

これで、任意の受信 URL に Access-Control-Allow-Origin ヘッダーが適用されます。CORS 仕様では、有効な Access-Control-Allow-Origin の値は *、null、または正確なオリジンだけです。オリジン内のワイルドカードパターンは使えません。特定の プレビュー URL から CORS を許可するには、_headers ファイルではなく Worker コード側で動的に処理する必要があります。

Google ↗ などの検索エンジンは、サイトのインデックス方法をクローラーに伝える X-Robots-Tag ヘッダーをサポートしていることが多いです。

たとえば、*.*.workers.dev の URL がインデックスされないようにするには、_headers ファイルに次を追加します。

https://:version.:subdomain.workers.dev/*
	X-Robots-Tag: noindex

フィンガープリント付きアセット（ファイル名にハッシュを含むアセット）のフォルダーがある場合、ブラウザー側でより積極的なキャッシュ動作を設定し、再訪問時の性能を上げられます。

/static/*
  Cache-Control: public, max-age=31556952, immutable

クリックジャッキングを防ぐには、X-Frame-Options ↗ ヘッダーで、ブラウザーにアプリケーションを別のページ内（例: <iframe>）へ埋め込まないよう伝えます。

X-Content-Type-Options: nosniff ↗ は、ブラウザーがレスポンスを Content-Type ヘッダーで定義されたもの以外のコンテンツタイプとして解釈しないようにします。

Referrer-Policy ↗ では、訪問者がページを離れるときに、どこから来たかの情報をどれだけ渡すかをカスタマイズできます。

ブラウザー機能は、Permissions-Policy ↗ ヘッダー（以前の名前は Feature-Policy）で段階的に無効化できます。

アプリケーションのコンテンツを細かく制御する必要がある場合は、Content-Security-Policy ↗ ヘッダーで、X-Frame-Options ヘッダーに似た制御を含む複数のセキュリティ設定を構成できます。

/app/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: no-referrer
  Permissions-Policy: document-domain=()
  Content-Security-Policy: script-src 'self'; frame-ancestors 'none';