リンク確認で405が出たらHEADとGETを比較する

数字だけでリンク切れと判断しない

ブラウザーではページが開くのに、確認ツールは405を返す。この違いは調査すべきことであり、すぐにリンクを削除する理由ではありません。受け取った応答上は、そのリソースで要求したメソッドがサポートされていないことを意味します。内容の存在、公開状態、すべての閲覧者の利用可能性を確認するものではありません。正確なアドレスと結果を出したツールを保存しましょう。

Stack Overflowには確認をGETからHEADに変更すると405が発生したという質問があり、Redditにはプログラムでのリンク確認の誤判定に関する質問があります。これらは利用者の報告であって、あなたの問題の原因を示す証拠ではありません。要求と内容を比べてから、リンク、確認ツール、サイト設定のどこを修正するか判断します。

HEADとGETの違い

GETはリソースの表現を要求し、HEADはGETに対応するメタデータを応答本文なしで要求します。MDNはこの違いを説明しています。ヘッダーだけなら転送量を減らせる場合がありますが、ページを読んだり、目的の文書があると確認したりはできません。アプリや中継システムが両方を正しく扱う保証もありません。拒否されたメソッドを記録してください。

RFC 9110は405応答に、そのリソースが現在サポートするメソッドを示すAllowヘッダーを含めるよう定めています。ツールに表示されるなら確認し、なければ欠落を記録します。値を想像したり、すべてのメソッドの許可が解決策だと考えたりしないでください。応答例は架空で、実サイトの採取結果ではありません。Allowも実際の確認の代わりにはなりません。

HTTP/1.1 405 Method Not Allowed
Allow: GET

解釈できる要求を比較する

サイト管理者でターミナル操作を理解しているなら、同じ公開読み取り用アドレスにHEADとGETを送って比較できます。コマンドはヘッダーを表示します。二つ目は本文を受信してから破棄するため、データをダウンロードする可能性があります。example.invalidは架空のドメインなので、確認を許可されたページに置き換えます。購入、削除、ログアウトなどの操作では試さないでください。

URLと管理できる条件をそろえ、時刻、メソッド、状態、転送の有無を記録します。コマンドはリダイレクトに追従しません。まず転送先を調べ、そこで再試行すべきか決めます。認証情報を追加したり、非公開Cookieを公開ツールに渡したりしないでください。ログイン中のブラウザーと別マシンの匿名要求は同条件ではありません。その違いを記録してから原因を考えましょう。

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

早まって結論を出さない

比較可能な条件でHEADが405、GETが200なら、その二つの要求が異なる応答を受けたと言えます。それでもページを開いて内容を確認する必要があります。GETも405ならHEADだけの問題と証明したことにはなりません。GETが404なら、先のHEAD確認はページの存在を証明していません。観察と仮説を分けて扱います。

エラーを消すためにフォームをPOSTからGETへ変更しないでください。動作が変わり、アドレスにデータが露出する可能性があります。便利だからと保護を無効化したり書き込みメソッドを許可したりもしません。自分のサイトならルーティングやサーバールールの担当者に結果を渡します。他人のサイトなら適切な公開リンクを求めるか、機密情報なしで問題を伝えます。

WikiURLの確認を追加する

完全な公開アドレスをWikiURLのURL確認ツールに貼り付け、HTTP状態と検出された最終アドレスを保存します。これはサービスのサーバーからの追加の観察です。自分のブラウザー、セッション、先のコマンドと同じ条件とは限りません。画面にHEADとGETを手動で選ぶ機能はないため、表示されないメソッド比較を行ったと説明しないでください。

次に本当の転送先をブラウザーで開き、想定読者に目的のページが見えることを確認します。結果が違えば、両方とその条件を残します。200は内容や安全性の認証ではなく、一度の405だけで削除を決められるわけでもありません。表示ラベルを診断全体とせず、具体的な箇所を修正する証拠を集めましょう。

共有前に検証可能な判断を残す

URL、日付、ツール、確認できたメソッドまたは未確認、状態、最終転送先、確認した内容を簡潔に記録します。実施していない試験は保留とします。必要なヘッダーからトークン、Cookie、個人情報を除いて保存してください。他の人には、裏付けのない結論ではなく、記録と期待する動作を渡します。

具体的な修正後は適切な範囲で再確認し、内容を確かめてからWikiURLで短縮したりQRを作ったりします。これらは共有を便利にしますが、サーバーの対応メソッドやリソースを修復しません。参照リンクを公開ファイルと保存すれば、クライアントの違い、メソッド拒否、誤った転送先を区別でき、一度の応答で有効なアドレスを失わずに済みます。