日本語のウェブページには歴史的にShift_JISやEUC-JPで書かれた古いHTMLが今も残っており、Content-Type: text/html; charset=Shift_JISのようにUTF-8以外を明示するレスポンスに出くわすことがある。charsetがレスポンスヘッダーとHTML内の<meta charset>タグで食い違っていると、ブラウザの文字コード判定が揺れて文字化けの原因になる——今も稀に発生する典型的な日本語特有のトラブルだ。
リクエストヘッダーとレスポンスヘッダーの違い
ブラウザはリクエストヘッダー（Accept、User-Agent、Cookieなど）をサーバーへ送り、自分自身と期待する内容を記述する。サーバーはその応答としてレスポンスヘッダー（Content-Type、Set-Cookie、Cache-Controlなど）を返し、返されるデータとブラウザへの指示を記述する。
Content-Typeが必要な理由
Content-Typeヘッダーは、レスポンス本文をHTMLページ、JSONデータ、画像、ダウンロードファイルのどれとして解釈すべきかブラウザに伝える。ここに正しい値がないと、ブラウザはJSONをプレーンテキストとして表示しようとしたり、逆にHTMLを誤って処理したりする可能性がある。
Cache-Controlがキャッシュを制御する仕組み
max-age=3600やno-cacheのような値は、サーバーへの新しいリクエストなしにリソースのキャッシュされたコピーをどれだけの期間使えるかをブラウザや中間サーバーに伝える。このヘッダーの誤設定は、ユーザーがサイトの古いバージョンを見てしまう一般的な原因だ。
なぜ必要なのか
- ブラウザがAPIレスポンスを誤って表示する理由を診断する。
Content-Typeのcharset指定とHTML内の<meta>タグの文字コードが一致しているか確認する。- サイトがHTTPSで配信されているか確認する——これはこのサイト自身のハッシュ・JWTツールが依存するWeb Crypto APIの動作に必須の条件だ。
同じヘッダーが複数回出てくる理由
HTTPでは同じヘッダーが1つのレスポンス内で複数回出現することが許されている — 最も一般的な例は複数のSet-Cookie行で、設定されるcookieごとに1行ずつ存在する。他のほとんどの重複ヘッダーは意味を変えずにカンマ区切りの1つの値へまとめられるが、Set-Cookieは意図的な例外だ。カンマがcookieの値の一部として正当に含まれる可能性があるためだ。