おなじみ「404」の真相は?
HTTPエラーコード入門 PART1――HTTPステータスコードの意味
HTTPステータスコードには複数の意味がある場合が多いので原因特定に苦労する。トラブルシューティングのポイントとなるHTTPエラーの3つのカテゴリーについて2回にわたって説明する。
HTTPのエラーコードのトラブルシューティングを経験した人であれば、その作業でイライラしたこともあるだろう。これらの暗号めいたコードには複数の意味がある場合が多いので、原因特定に苦労するのだ。わたしの経験からいえば、HTTPエラーは3つの主要なカテゴリーに分類される──ユーザーのデバイスに関連した問題、Webサーバに関連した問題、そして接続に関連した問題だ。HTTPエラーのトラブルシューティングを効果的に行う上で重要なポイントは、その問題がこれらのカテゴリーのどれに入るのかを判断することだ。本連載ではその方法を示したい。
HTTPステータスコード
現在直面している問題を理解する上でカギとなるのは、HTTPステータスコードに関する知識だ。クライアントがHTTPリクエストをWebサーバに送信すると、サーバは応答コードを返す。これらの応答コードは、5つのカテゴリーに分類されている。
100番台のコード
HTTPステータスコードの100~199番は、通知コードだ。これらのコードを実際に目にすることはめったにない。その理由は2つある。まず、ブラウザがWebサイトにアクセスしてこれらのコードが返されたとしても、通常はそれが画面に表示されることはない。これらはブラウザに通知される内部的コードにすぎないのだ。これらのコードにお目にかかることが少ないもう1つの理由は、最初のHTTP規格では、100番台のコードが認められていなかったからだ。このため、これらのコードは今でもあまり使用されていない。
200番台のコード
200~299番のステータスコードは、成功を示すコードだ。これらのコードも、通常のWebサーフィン中に画面に表示されるのを見ることはまずないだろう。これらは、リクエストの成功と現在の状態を確認する手段としてブラウザで内部的に使用されるだけだ。通常は表示されないこれらのコードを読み出せる診断ツールもある。ほかのHTTPステータスコードと同様、200番台のコードも診断プロセスで貴重な情報を与えてくれることがある。
300番台のコード
300~399番のステータスコードは、リダイレクションコードだ。これらのコードは基本的に、リクエストを実行するためには、ほかの処理を実行しなければならないことをブラウザに通知するものだ。この処理は自動的に実行されるものもあれば、ユーザーによる追加入力を要求するものもある。例えば、ステータスコード301は、特定のリソースが恒久的に移動し、以後そのリソースに対するすべての呼び出しは特定のURLを参照しなければならないことを示す。
400番台のコード
400番台は、クライアント側のエラーを示すコードだ。これらのエラーコードは、セキュリティに関連している場合が多い。例えば、クライアントがアクセスを許可されていないリソースへのアクセスを試みると、サーバはステータスコード401を返す。同様に、クライアントが未許可のリソースへのアクセスを試み、クライアントの認証ステータスによっても状況が変化しない場合には、サーバはステータスコード403を返すことがある。これは、そのリソースへのアクセスが禁じられていることを示す。
400番台のコードは、リクエストが不正な形式であったり、クライアント側でタイムアウトが起きたりすると返されることもある。400番台のコードで誤解しやすいのが404だ。このコードは、技術的にはクライアント側のエラーとして分類されているが、実際にはクライアント側またはサーバ側のいずれかのエラーを表す。このエラーは、リクエストされたリソースが見つからなかったことを示しているだけだ。このエラーがクライアント側で起きた場合、ネットワーク接続の問題が原因であることが多い。それ以外にも、リソースがサーバから削除されるか、リソースの名前が変更されたために、このエラーが発生する場合もある。
500番台のコード
500番台のステータスコードは、サーバのエラーを表す。例えば、Webサーバでタイムアウトが発生すると、504エラーが返される。ただし500番台のエラーは、サーバの問題ではなく、サーバ上で動作しているWebアプリケーションの問題を示していることも多い。例えば、わたしの個人Webサイトは、HTMLページを動的に生成するASPでコーディングされている。このサイトのデバッグ作業中に、コードのバグのせいでわたしのWebサーバからHTTPステータスコード500が返されることが何回もあった。これは、サーバの内部エラーを示す一般的なコードだ。このコードは、何らかの問題が発生し、HTTPがそれをどう処理していいか分からないことを示しているだけだ。
まとめ
以上で述べたように、各HTTPコードは問題の原因について多くの手掛かりを提供してくれる。しかし、さらに多くの情報を収集しないと問題を解決できないこともある。幸いにも、そのようなときに役立つ無償のトラブルシューティングツールが幾つか存在する。本連載のPART2では、トラブルシューティング作業に役立つツールの使い方を説明する予定だ。
本稿筆者のブライエン・M・ポージー氏はMCSE(マイクロソフト認定システムエンジニア)の資格を持ち、Windows 2000 ServerおよびIISに関する仕事でMicrosoft Most Valuable Professionalの認定を受けた。全米規模の病院/医療施設チェーンでCIO(最高情報責任者)を務めた経験を持つほか、フォートノックス(ケンタッキー州にある米軍施設)のネットワーク管理者を務めたこともある。フリーランスのテクニカルライターとして、Microsoft、CNET、ZDNet、TechTarget、MSD2D、Relevant TechnologiesなどのIT関連企業に記事を寄稿している。同氏の個人WebサイトのURLはwww.brienposey.com。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選 -
技術文書・技術解説
[日本オラクル株式会社] 無自覚なリスク 秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由 -
製品資料
[日本オラクル株式会社] 戦略的経理の第一歩 失敗のない「脱Excel」を実現する秘訣とは? -
技術文書・技術解説
[日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い 最適な製品をどう見極める? -
事例
[株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
4
エンジニアの生産性はどう測る? マネジメントに不可欠な可視化の実現方法とは
-
5
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
6
ただなのに「12時間以内の復旧」も要求 無償OSSに商用レベルを求める企業の末路
-
7
「IoT通信環境の構築・運用」に関するアンケート
-
8
生データを隠してデータ連携 KDDIが4000万人の顧客情報を安全に分析できた理由
-
9
「Copilot」はなぜ放置される? “議事録要約止まり”を脱する処方箋
-
10
大阪証券取引所がHiRDBで実現した「世界トップレベルの応答速度」を誇る新売買システム
ホワイトペーパーランキング PR
-
1
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
2
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
バックアップは“取っているから大丈夫”なのか? ランサムウェア時代の備え方
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
5分で分かる Microsoft 365のデータ損失に備えるためのバックアップの仕組み
-
9
ネットワーク遅延の原因、「パケットロス」の基礎知識と効果的な解決策
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー