HTTPヘッダーの検索

HTTPヘッダーの検索は、指定したURLに通常のGETリクエストを送信し、返されるすべてのHTTPレスポンスヘッダーを取得できる無料ツールです。

HTTPレスポンスヘッダーとは？

HTTPレスポンスヘッダーとは、WebサーバーがHTMLページ、画像、JSONドキュメントなどのレスポンス本文より先に送信するメタデータです。レスポンスの解釈方法、キャッシュ、リダイレクト、セキュリティに関する情報をクライアントへ伝えます。

HTTP/1.xのレスポンスは通常、HTTPステータス行で始まり、その後にヘッダーが続きます。HTTP/2とHTTP/3では、同等のステータスが:status疑似ヘッダーで送られます。厳密には、HTTP/1.xのステータス行はヘッダーとは別ですが、リクエストが成功したかどうかを示すため、一般にはヘッダーと一緒に表示されます。200はリソースが返されたこと、301または302はリダイレクト、404はリソースが見つからなかったこと、500はサーバー側のエラーを示します。

ヘッダーは、オリジンサーバー、リバースプロキシ、Cloudflareなどのコンテンツデリバリーネットワークから追加される場合があります。レスポンスがこれらのシステムを通過する間に、一部のヘッダーが追加または削除されることもあります。そのため、結果に表れるのはページを生成したアプリケーションの情報だけとは限りません。

HTTPヘッダーを調べるには？

https://www.example.com/accountのように、スキームを含む完全なURLを入力してください。ツールのサーバーから通常のGETリクエストが送信され、そのURLから受信したHTTPヘッダーが返されます。

レスポンスヘッダーを正確に比較するには、調査したいURLをそれぞれ完全に一致させて使用してください。http://example.com、https://example.com、https://www.example.comでは、個別にリダイレクト、キャッシュルール、サーバー設定が適用される可能性があるため、ヘッダーが異なる場合があります。

URLの構文もリクエストに影響します。

• 空白はそのままではURLに使用できません。通常はパーセントエンコードが必要で、パスでは一般に%20と表します。
• ?はクエリ部分の開始を示します。&と=はフォーム形式のクエリエンコードでよく使われますが、すべてのクエリ文字列で同じ役割を持つわけではありません。
• アクセント記号付き文字や非ラテン文字を含むドメイン名はIDNAで処理され、ASCIIのA-labelとして表されます。一般にxn--で始まります。一方、パス内の文字は通常、UTF-8のバイト列に変換された後、パーセントエンコードされます。
• #で始まるフラグメントはブラウザー側で処理され、HTTPリクエストには送信されません。
• URLの長さに共通の上限はありません。ただし、非常に長いURLはサーバー、プロキシ、アプリケーションに拒否される場合があります。

HTTPヘッダーの結果はどう読めばいい？

調査中の問題に関係するヘッダーを確認してください。ヘッダー名では大文字と小文字が区別されませんが、値の構文では区別される場合があります。

アプリケーション固有のヘッダーもあります。たとえば、Access-Control-Allow-Originは、ブラウザーのクロスオリジンリクエストを通じてレスポンスを読み取れるオリジンを制御します。Serverヘッダーにはソフトウェア名やプロキシ名が記載されることがありますが、管理者が変更または削除できるため、実際の基盤を示す確実な証拠にはなりません。

よくある問題の調査例

ヘッダーを確認する一般的な理由の一つが、リダイレクトの問題です。たとえば、https://example.com/old-pageがステータス301とLocation: https://example.com/new-pageを返したとします。これは、新しいアドレスへリクエストを送るようサーバーがクライアントに指示しているという意味です。各移動先を順番に確認すると、リダイレクトループや、HTTPとHTTPSの間で発生する意図しない切り替えを見つけられます。

CloudflareなどのCDN経由で古いページが表示される場合は、Cache-Control、Age、ETag、サービス事業者固有のキャッシュヘッダーを確認してください。Ageの値が大きい場合、それはキャッシュされたレスポンスの算出上の経過時間を示します。上流キャッシュに存在した時間が含まれる可能性があり、特定の中継サーバーが保持していた時間とは限りません。また、すべての地域のキャッシュが同じバージョンを保持している証拠にもなりません。

APIがサーバー側のスクリプトでは動作するのにブラウザーでは失敗する場合は、Content-Typeと、Access-Control-Allow-Originを含むCORSレスポンスヘッダーを確認してください。JSONエンドポイントがtext/htmlを返しているなら、実際にはエラーページやログイン画面が配信されている可能性があります。クロスオリジンの許可がないと、サーバーがステータス200を返していても、ブラウザーがアクセスをブロックすることがあります。

サイトにアクセスできないように見える場合も、ヘッダーが手掛かりになります。503レスポンスはサーバーまたは上流側の一時的な障害を示唆し、404は要求したパスが見つからなかったことを意味します。ただし、すべての障害を診断できるわけではありません。HTTPレスポンスが生成される前にDNS名前解決、TCP接続、TLSネゴシエーションが失敗すると、確認できるレスポンスヘッダー自体が存在しない場合があります。接続状況はピングで別途確認でき、プロトコルへの対応状況はHTTP/2チェッカーで調べられます。

正しい結果なのにおかしく見えるのはなぜ？

キャッシュ、DNSレコード、リクエスト時の条件によって異なるレスポンスへ振り分けられるため、正しい結果でもブラウザーでの表示と違う場合があります。この検索はサーバー上で実行されるので、ローカルネットワークとは異なるCDNノードに接続したり、変更直後のDNSレコードがローカル環境より早く、または遅く反映されたりすることがあります。

ブラウザーは独自のCookie、受け入れ可能なコンテンツタイプ、言語、キャッシュ検証子も送信します。そのため、ログイン済みのWordPressページでは、匿名のサーバーリクエストと異なるキャッシュルールが返される場合があります。地域別ルーティングやボット管理システムによって、接続元のネットワークやリクエストヘッダーに応じてレスポンスが変わることもあります。

DNSを変更した後も、キャッシュDNSリゾルバーはTTLが切れるまで以前のレコードを使い続けることがあります。通信が新しいサーバーに到達するようになっても、古いCDNオブジェクトやブラウザーキャッシュから以前のコンテンツが返される場合があります。名前解決されたホストを別途確認し、必要に応じてキャッシュを削除してください。また、すべてのホスト名が同じ設定だと思い込まず、完全に同一のURLで比較することが重要です。

よくある質問

リクエストヘッダーも表示されますか？

いいえ。取得できるのは、通常のGETリクエストに対してURLから返されたレスポンスヘッダーです。リクエストヘッダーはサーバーへ送信されるメタデータで、すべて確認するにはブラウザーの開発者ツール、サーバーログ、コマンドラインクライアントなどを別途使用する必要があります。

入力したURLは非公開ですか？

検索処理はサーバー上で行われます。入力内容はHTTPS経由でそのサーバーへ送信され、保存されません。パスワード、アクセストークン、機密性の高いクエリパラメーターを含むURLは入力しないでください。リクエスト時には、接続先のサーバーにもそれらの値が送信されます。

HTTPヘッダーで証明書の警告原因を調べられますか？

通常、HTTPヘッダーだけでは調べられません。TLS接続はHTTPレスポンスが送信される前に確立されるため、証明書の有効期限切れ、ホスト名の不一致、信頼されていない発行者などが原因で、ヘッダーが一切返されない場合があります。ページが読み込まれる前にブラウザーの警告が表示される場合は、証明書と証明書チェーンを別途確認してください。

Set-Cookieヘッダーが複数返されるのはなぜ？

1つのレスポンスで複数のCookieを設定でき、それぞれのCookieに個別のSet-Cookieフィールドが使われるためです。Cookieの有効期限自体にカンマが含まれることがあるので、カンマ区切りの一覧のように結合しないでください。各Cookieのドメイン、パス、セキュリティ属性を個別に確認しましょう。

curlの結果と比較できますか？

はい。curl -D - https://example.com/ -o /dev/nullのようなコマンドを実行すると、レスポンス本文を破棄しながらレスポンスヘッダーを表示できます。Curlのバージョン、リクエストヘッダー、リダイレクト設定、ネットワーク上の場所によって結果が変わる場合があります。差異をサーバーの不具合と判断する前に、これらの条件をそろえてください。