覚えているようであまり覚えていないHTTPのステータスコードを覚書でまとめました。
HTTPステータスコードとは
HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードで、RFC 2616、RFC 7231等によって定められている。
Webシステムを構築する人にとって、全ステータスを覚えろというわけではないですが、
- 1xxは情報
- 2xxは正常
- 3xxはリダイレクト（移動）
- 4xxはクライアント側起因のエラー
- 5xxはサーバ側起因のエラー
と頭1つ目の数字だけ覚えていたらOKです。
1xx ～Informational（情報）～
1xxは情報と呼ばれています。
正常でもなければエラーでもない。仮のコードとして定義されているものになります。
注意すべきはHTTP/1.0では1xxのステータスコードは使えないことに注意してください。
といってもHTTP/1.0なんてほぼ使われていないと思いますけど。
100 Continue ～継続～
Continue（継続）という名の通り、このステータスコードは処理中の最中にあり、サーバ側からクライアントへ続きを送信する際に使うステータスコード。
サーバーへ送信する際にはリクエストヘッダ情報に【Expect】が必要になるようです。
- サーバーへリクエストヘッダを投げる（この時にExpect: 100-continueを付与）
- サーバーから100 Continueが返ってくる
- サーバーへリクエストボディを送信する
といった流れになるようです。
AWSの情報をみるとリダイレクトとかする際にリクエストヘッダ＋リクエストボディを同時に送ると遅くなるからヘッダのみ送付し、効率化させるために使うみたい。
HTTP/1.1 100 ContinueRFC 2616 Section 8.2.3
AWS（リクエストのリダイレクトとREST API）
101 Switching Protocols ～プロトコル切り替え～
プロトコルの切り替え要求のステータスコード。
Websocket通信で多く使われているみたいです。
あとはHTTP 1.0でリクエスト投げてきた奴に対してHTTP 1.1またはTLS1.1で通信させようとする場合にも使います。
- クライアント「HTTP1.0でサーバに送信するよ！(/・ω・)/」
- サーバー「うち、HTTP1.1じゃないとダメなんよ。HTTP1.1したいから切り替えてね( ˘•ω•˘ )」
- クライアント「わかった、切り替えるね！(/・ω・)/」
といった感じでしょうか。
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: UpgradeGET /resource HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: upgradeRFC 7231 Section 6.2.2
WebSocketについて調べてみた。
102 Processing ～処理中～
WebDAVの拡張ステータスコードで処理中を意味します。
サーバはリクエストを受け取っているが、処理中の為、リクエストが返却できない状態に返却されるステータスです。
要するに、クライアント側でタイムアウト等で勝手に切断しちゃだめよってことです。
HTTP/1.1 102 Processing103 Early Hints ～ヒント～
HTTP/1.1及びHTTP2のリソース配信の最適化に利用するために2017年12月に制定されたステータスです。めっちゃ最近！
ステータスコードはコンテンツの生成が終わった後に決定されるものなので、コンテンツの生成が終わるまでレスポンスが返せない仕様になっています。
そのため、他にデータが欲しいことが発覚するのにもレスポンスが返ってきてからになるため完了まで時間がかかるのがネックでした。
それが、このステータスコードは先行してレスポンスを返すことができるようです。
HTTP2で新しくできたLinkヘッダの情報を先にクライアントへ送ってあげることで他に必要なファイルが早くわかり、画面表示の高速化が図れるみたいです。
でも、2018年8月20日時点でも実験段階の模様なので標準化され、ブラウザが対応するまでは時間がかかりそう。特にIE11。
これを使うことでメインヘッダを送る前にJavaScript、CSSの取得を行うことができ、高速化が図れるようになるみたいです。
このステータスを使う＝IE11非対応宣言になるんじゃないかな。または308と同じようにIE11とOSの組み合わせ問題があるかもだし。
RFC 8297
HTTP の新しいステータスコード 103 Early Hints
IFTF（An HTTP Status Code for Indicating Hints）
Hacker News（HTTP 103 – An HTTP Status Code for Indicating Hints）
2xx 正常
2xxは正常終了のステータスコードになります。それだけ。
種類は11種類もありますが、最低、200と204だけ覚えておけばOKだと思います。
200 OK ～OK～
Webシステムを構築する以上、100％お目にするステータスコード。
リクエストがちゃんとサーバに届き、要求に応じた情報が返ってくるときに使われるコードです。ちなみにキャッシュ可能
O━━d(ゝω・´)━━K!!!
HTTP/1.1 200 OK
Date: Sat, 06 Apr 2018 21:10:39 GMT
Server: nginx
Content-Length: 490
Content-Type: text/html; charset=iso-8859-1
・
・
・201 Created ～作成～
200のOKとは違い、リソースの作成が完了したことを表すレスポンスコードであり、主にPOST・PUTメソッドを使われた際に返すステータスコード。
POSTメソッドは少しややしくて
- REST方式じゃない場合のPOSTメソッドは基本的に200。
- REST方式の場合は200だったり201だったり
とRESTかどうかでステータスが分かれる場合があるみたいです。
HTTP/1.1が策定されたのが1997年と20年以上経っており、ちょっとごちゃごちゃになっているのが現状。
201はキャッシュ不可なので201のほうがいいのでは？という意見も。
ただ、201で返した場合はLocationヘッダが入ることものようです。
イメージ的には
- クライアント「このデータ送るからファイル作ってー(/・ω・)/」
- サーバ「りょうかい！URLは＊＊＊＊な(*´ω｀*)」
といった感じでしょうか。
HTTP/1.1 201 Created
Date: Sat, 06 Apr 2018 21:10:39 GMT
Server: nginx
Content-Length: 490
Content-Type: text/html; charset=iso-8859-1
・
・
・202 Accepted ～受理～
処理は受け付けたが、完了していないステータスコード。
役所とかで書類を提出して待たされるような状態に近いかも。
102と違うのは
- 102・・・リクエスト情報の処理中
- 202・・・リクエスト情報は処理OK、情報の作成中
だと思います。
203 Non-Authoritative Information ～信頼できない情報～
Proxyによって200⇒203に変換されたステータスコード。
ローカルからの情報も203になることがあるのでサーバから直接受け取ったデータではないと覚えたらいいかもです。
メッセージ通り、サーバから直接受け取った情報ではないので信頼できない（改変されている可能性のある）情報です。
204 No Content ～内容なし～
201のリソースがない版のステータス情報がこれにあたり、
200のページ更新が不要な場合もこのステータスになります。
要するにPOSTやPUTメソッドにてデータを送信し、中身（Body）は一切ないヘッダ情報だけ返すステータスコードです。
204を受け取った場合、ブラウザは何もしません。だって中身がないもの。
サンプルコード
下記のHTMLとPHPと用意
<form action="https://kaede.jp/test2.php">
<input type="text" name="test" value=""/>
<input type="submit"/>
</form><?
#↓のステータスコードで200と204を検証
header ("HTTP/1.1 200");
?>送信前情報
テキストボックスに「aaa」を入力して送信
200で返却された場合、サーバから受け取った情報をもとに画面が再描写されます。
204で返却された場合、画面は再描写されず送信前のデータのままになります。
画面再描写しないため、URLも変更されません。
205 Reset Content ～内容リセット～
204と同じで中身（Body）は一切ないヘッダ情報だけ返すステータスコード。
違うのはブラウザは何もしないわけではなく、resetボタンを押下された状態（初期状態）と同じ状態にするみたいです。
Chromeで検証したら204と同じ結果になったので本当にそうなるのか未検証です。
206 Partial Content ～部分的内容～
音声や動画などのストリーミング通信を行う際に使われるステータスコード。
クライアント⇒サーバに送付する際にはRangeヘッダーを送付してサーバに欲しいデータの範囲を指定します。
If-Rangeを使うことで取得したいデータの範囲を複数指定することも可能です。
RFC 7233 Section 4.1
MDN 206 Partial Content
207 Multi-Status ～複数ステータス～
WebDAVで使われるステータスコード。
クライアントが複数個のデータ操作（GET・POST・PUT・DELETE等）の場合に各データに対しての結果が異なる場合、それぞれ操作に対する情報をxml形式で返すみたいです。
200番台なので表向きは「成功」だが、複数のデータに対しての情報は別扱いなのでxmlデータを見るとエラーだったりします。
（1ファイル目は200、2ファイル目は300、3ファイル目は400、4ファイル目は500のステータスコードだとしても207でまとめて表示されます。）
208 Already Reported ～既に報告済み～
WebDAVで使われるステータスコードです。2010年に策定され、比較的新しいステータスコード。
propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly
WebDAV等でバインディング（対応付け）等にて、すでに行っていた場合に返されるものだと思います。
こちらを見ると「Depth:infinity」の場合のみに発生するコードみたいです。
226 IM Used ～IM使用～
IM（instance manipulation：インスタンス操作）だよ。インスタントメッセージじゃないよ。
Delta encoding in HTTP言われる差分符号化技術をHTTP上で使う際に使われるステータスコードです。
要するに、前回送信したデータと比較し、差分情報のみをやりとりするのに使われるステータスコード。
Webページなんて毎回新しく作られるものではないというのを着目して差分だけデータのやりとりすれば効率よくなるんじゃね？というのを基に作られた規格のステータスコード。
リクエストにはA-IMヘッダー、応答にはEtagヘッダーが必要だとか。
過去も今もあまり使われてなかったりする。
RFC 3229 Section 10.4.1
自由研究：フィード巡回ボットのHTTPリクエスト観察日記
差分符号化 (HTTP)
3xx リダイレクション
指定したページに転送させることをリダイレクションといいます。リダイレクトとも言われている。
- クライアント「http://aaa.com/bbb.htmlのデータクレ！(/・ω・)/」
- サーバー「http://aaa.com/fff.htmlで再度問い合わせしな( ﾟДﾟ)」
- クライアント「わかった！(;´･ω･)」
- クライアント「http://aaa.com/fff.htmlのデータクレ！(/・ω・)/」
＼ ⊂[J( 'ｰ`)し ＜ほらよ！
＼/ (⌒ﾏ´
（⌒ヽrヘJつ
＞ ）、
し' ＼） ヽヾ＼
丶ｎ.＿
http://aaa.com/fff.html
￣ （⌒
⌒Y⌒300 Multiple Choice ～複数選択～
サーバ「複数のレスポンスを返すからどれか好きなものを選べ！」というステータスコード。
要求されたリソースの表現方法がいくつかあり、どれを返せばいいのかわからない場合に使われるみたいですが、あまり見かけないですね。
200か400で返すことのほうが多いような気がする。
選択肢の中からどれを選ぶのか標準化されていないため、クライアント依存となります。
例としてhttps://www.w3.org/TR/xhtml11/DTD/xhtml11.htmlがあります。
301 Moved Permanently ～恒久的な移動～
恒久的なURL移動をする際に使われるステータスコード。
Locationヘッダ必須で、Locationヘッダに移動先のURLが記載されている。
ドメイン変更やページ名などのURLを変更した場合、通常は古いURLにアクセスできないがリダイレクトを使うことで新しいURLに導くために使う。
301はPOST送信された場合もGETメソッドに変換されて送信されるので注意が必要です。
POSTメソッドのまま恒久的な移動を行いたい場合は308を使います。
302 Found ～発見した～
RFC2068のときは「Moved Temporarily ～一時的に移動した～」だったがWikiや掲示板などで投稿した際に別URLへ転送したいときに302を乱発されてしまったため、RFC2616で変更されたみたいです。
本来は一時的にそのURLに存在せず、別のURLにある場合に返すステータスコードだったんですけどね。
乱用された302を解消すべく、303、307が新しくできあがりました。
今は目的に応じて使い分けるようにするべきとされています。
使用例としてはメンテナンスページ等で使われます。
302はPOST送信された場合もGETメソッドに変換されて送信されるので注意が必要です。
POSTメソッドのまま一時的な移動を行いたい場合は307を使います。
303 See Other ～他を参照～
Wikiや掲示板などで投稿した際に別URLへ転送したいときに使うために使われるステータスコード。
- 掲示板やフォーラムなどで書き込み
- 投稿ボタン押下
- 投稿画面ではなく、一覧画面へ遷移（ステータスコード：303）
といった例になると思います。
注意事項としてはこのステータスコードはGETメソッド強制になってしまいます。POSTメソッドのまま転送させたい場合は307か308を使わざるを得なくなります。
304 Not Modified ～更新されていない～
「クライアントのキャッシュ情報を使用してくれ！」になります。
このステータスコードを表示するには
- サーバ⇒クライアントへ以前取得したヘッダ情報に「Last-Modify」ヘッダが入っている
- クライアント⇒サーバへ「If-Modified-Since」ヘッダに「Last-Modify」ヘッダの情報を入れて送信
- サーバは「If-Modified-Since」を受け取り、サーバ内にあるデータの更新日付と比較
- サーバ⇒クライアントへ更新日付のほうが新しければ最新データを送信し（ステータスコード：200）、古ければデータを送信せず（ステータスコード：304）を返す
- クライアントはステータスコードを確認し、304の場合はローカルに保存しているデータを呼び出す
という流れになります。
304は内部データ（body）を送らない分早いですが、ファイルの最新情報を確認する必要があるためサーバ負荷は発生します。
そのため、ファイルの取得に時間がかかるサーバだとレスポンスが悪い場合があります。
305 Use Proxy ～プロキシ使用～
このステータスコードを受け取ったクライアントはLocationヘッダに記載されたURLをプロキシ経由でアクセスします。
直接サーバからデータを取得するのではなくプロキシサーバを介してデータを取得しろってことですね。
ちなみにこのステータスコードはRFC 7231（2014年）で廃止された模様。
いつか306と同じくUnusedに変わるかも。
306 Unused ～未使用～
Switch Proxyとして使われようとしていたが検討段階でお蔵入りになり、欠番（正式には予約扱い）になったステータスコード。
306が使われることはもうないのかもしれない（－人ー）
307 Temporary Redirect ～一時的なリダイレクト～
302が乱用されまくたっために、302本来の使い方を改めて定義したもの。
クライアントは307を受け取ると、Locationヘッダに記載されているURLへメソッドを変更せずに再送信します。
使い方は302と類似だけどメソッドが変わらないことに注意が必要です。
308 Permanent Redirect ～恒久的なリダイレクト～
使い方は301と類似で、Locationヘッダに指定された別のURLへ恒久的に移動されていることを指す。
クライアントは308を受け取ると、Locationヘッダに記載されているURLへメソッドを変更せずに再送信します。
使い方は301と類似だけどメソッドが変わらないことに注意が必要です。
2015年に制定された新しいステータスコードなのですが、Windows7のIE11は使えない模様。（Windows8.1、Windows10のIE11は使えるみたい）
そのため、308を使いたい場合は2020年1月14日のWindows7滅亡まで待ちましょう。（stackoverflowやingress-nginxより）
※（301、302）、（307、308）は恒久的・一時的のステータスコードの順序が逆になっているので注意。
| 恒久的 | 一時的 | |
|---|---|---|
| POST⇒GETへの変更を許可 | 301 | 302 |
| POST⇒GETへの変更禁止 | 308 | 307 |
RFC 7538
HTTPステータスコードに追加された「308」とは？
4xx クライアントエラー
主にクライアントから送られているくるリクエスト情報に誤りがあるために返答されるステータスコードです。
全28種類あるが、代表なステータスコード（400、401、403、404）だけ覚えておけばいいと思う。
400 Bad Request ～リクエストが不正である～
定義されていないメソッドやリクエストヘッダにおかしな情報があるなど、リクエスト情報がおかしい場合に返されるステータスコード。
Cookie情報が古すぎたり、リクエストサイズが大きすぎたりするとこのステータスコードを表示される場合もある。
リクエストヘッダだと、「Content-Length」が複数個あったり、数値以外が入ったりなど。
401 Unauthorized ～未認証～
Basic認証やDigest認証を行う際に表示されるステータスコード。
このステータスコードを受け取ったブラウザは認証ダイアログを表示し認証処理を行います。
402 Payment Required ～支払いが必要である～
実装されていなく、予約されたステータスコード。
デジタル支払いを目的としたステータスコードだったみたいですが、現時点使用されていないです。
RFCも下記の通りざっくりとした説明のみです。
The 402 (Payment Required) status code is reserved for future use.
403 Forbidden ～禁止されている～
アクセス禁止なデータ・リソースに接続した際に表示される。
会員のみ閲覧できるサイトを非会員がアクセスした場合やBasic認証にてアクセス許可できないユーザがログインしている場合等
404 Not Found ～未検出～
4xx系のステータスコードだと404が最もよく見るステータスコード。
- アクセスしたがファイルが見つからない
- アクセス権がない（403エラーを隠すために使われる）
が想定される。
Java系のWebサーバだと設定によってはJSPに直接アクセスされた場合に404を返したり。
メールで送られてきたURLのコピペミスで表示されない場合も404系が多い。
Googleクロールでは404と410（Gone）でクロール頻度が変わったりするみたいです。（詳細は410（Gone）を参照）
405 Method Not Allowed ～許可されていないメソッド～
Webサーバによって使えるメソッドに制限があり、制限されたメソッドを使った場合に返されるステータスコード。
POSTの使用禁止しているWebサーバでPOST送信した場合に表示される。
406 Not Acceptable ～受理できない～
WebサーバがRestful通信等、サーバ側でリクエストヘッダフィールドの情報を参考にして自動的に行う場合、クライアント側から受け取った情報に見合うコンテンツが見つからなかった場合に送信されるステータスコード。
例えば、
- サーバは英語か日本語しか受け付けられないが、リクエストのAccept-Language:ヘッダにzh（中国語）しか含まれていなかった。
- サーバはapplication/pdfを送信したかったが、リクエストのAccept:ヘッダにapplication/pdfが含まれていなかった。
- サーバはUTF-8の文章を送信したかったが、リクエストのAccept-Charset:ヘッダには、UTF-8が含まれていなかった。
など。
407 Proxy Authentication Required ～プロキシ認証が必要～
プロキシサーバが認証を求めている場合に使用されるステータスコード。
401と同じくRFCは7235になっている。
408 Request Timeout ～リクエストタイムアウト～
アイドル状態のコネクションにおいて、サーバがコネクションを閉じたい場合に送付されるステータスコード。
409 Conflict ～競合～
ファイルに存在しているファイルよりも古いバージョンをPUTメソッドにてファイルを送信した場合、に応答されるステータスコード。
SVNなどバージョン管理システムで使われる。
410 Gone ～消滅～
404は一時的な削除という扱いに対して410は永久に削除したと扱われる。
Googleの場合、404よりも410にすればファイル確認のクロール頻度が下がるようです。
といっても404が複数回発生した場合はクロール頻度を下げるようなのでとくにやらなければならないっていうわけでもないですけどね。
RFC 7231 Section 6.5.9
ranking for "art supplies"
411 Length Required ～Content-Lengthがない～
リクエストヘッダにContent-Lengthヘッダがない場合に返されるステータスコード。
412 Precondition Failed ～前提条件の失敗～
サーバ側で適合しない前提条件がヘッダー情報に入っている場合に表示されるステータスコード。
例えば、
- If-Unmodified-Since（キャッシュの更新確認）
- クライアントが保持しているキャッシュ日付がサーバ側で保持している最終更新日よりも新しい場合
- If-Match（ETag確認）
- クライアントが持っているETagの値がサーバに存在しない場合
- If-None-Match（ETag確認）
- リクエストメソッドが「GET」、「POST」以外の場合
の場合に412を返却するようである。
RFC 7232 Section 4.2
[対処法] 412 Precondition Failed
413 Payload Too Large ～ペイロードが長い～
ApacheやNginxの場合は「413 Request Entity Too Large」 と表示されたりする。（そもそもRFC2616以前では「Request Entity Too Large」だったため）
bodyメッセージ部分のデータ量がWebサーバで指定されている値よりも多く受信した場合に返却される。
（例えばWebサーバは10MBしか許容しない設定なのにクライアントサーバは100MBのファイルを送信しようとした場合など）
対処方法はWebサーバの許容量を上げるか、送信サイズを小さくすることになる。
414 URI Too Long ～URLが長い～
名前の通りURLが長すぎる場合に表示される。
Apacheやnginxの初期設定では8KB（8190）なので、それ以上にURLに記載された場合に発生する。（画像などをGETメソッドで送信した場合等に発生しやすい）
た だ し、IEの場合はURLに記載できる文字数は2083文字までなのでWebサーバ側の問題というよりもIEが原因だったりする。
RFC2616以前は「Request-URI Too Long（リクエストURLが長い）」と表記されていたため、一部のWebサーバでは「Request-URI Too Long」と表記されたりする。
415 Unsupported Media Type ～サポートされていないメディアタイプ～
リクエストされたデータの形式がサーバ側で対応していない場合に返されるステータスコード。
416 Range Not Satisfiable ～レンジは範囲外～
206 Partial Content ～部分的内容～における処理で、Rangeヘッダの値にて
- Rangeヘッダの範囲にて数値や「-」が入っていない
- 指定範囲が妥当ではない
場合に返されるステータスコードである。
417 Expectation Failed ～Expectヘッダの失敗～
サーバが100 Continue「継続」が使えない場合やExpectヘッダに100-continue以外のものが入っている場合に返されるステータスコード。
418 I'm a teapot ～私はティーポッド～
エイプリルフールネタのステータスコード。
ちなみに、HTTPのステータスコードではなく、HTCPCP（Hyper Text Coffee Pot Control Protocol）であることもジョークネタになっている。
そのため、HTTP上で418を実装してはいけないのでは？という議論があったりする。（golangとかnodejsなど）
実際にIANAで正式に定義・登録されているものではないという理由もあるんですけどね。RFCにはあるけど。
ただ、最近418を予約語とする動きがあったり。今後の動向に期待
RFC 2324 Section 2.3.2
HTTPで「418 I’m a tea pot」を実装してはいけない(2017/09/12追記)
421 Misdirected Request ～誤ったリクエスト～
レスポンスを生成できないサーバにて返答されるステータスコード。
422 Unprocessable Entity ～処理できないエンティティ～
WebDAVの拡張ステータスコード。
リクエスト情報が正しいものの、処理できなかった場合に返答されるステータスコードである。
423 Locked ～ロックされている～
WebDAVの拡張ステータスコード。
リソースがロックされている場合に返答されるステータスコードである。
424 Failed Dependency ～依存関係で失敗～
WebDAVの拡張ステータスコード。
前のリクエスト失敗したことによって返されるステータスコードである。
426 Upgrade Required ～アップグレード要求～
現在のプロトコルでの要求は拒否し、指定したプロトコルを変更して接続を行うように支持するステータスコード。
あれ？101 Switching Protocolsと似てない？
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol428 Precondition Required ～前提条件が必要～
あるヘッダ情報必要なのにも関わらず送信されていない場合に返されるステータスコード。
たとえばIf-Matchがヘッダが欲しいのになかったりとか。
429 Too Many Requests ～リクエストが多すぎる～
一定時間内に大量のリクエスト送信を行った場合に返されるステータスコード。
JMeterとかで負荷テストを行ってみた際にやりすぎて返されるステータスコードであったりする。
431 Request Header Fields Too Large ～リクエストヘッダーフィールドが大きすぎます～
ステータスコードの名称通り、ヘッダーフィールドが大きすぎるためにサーバが処理できない場合に返されるステータスコード。
このステータスコードはヘッダーフィールド数が多すぎる場合や１つのヘッダーフィールドが大きすぎる場合に使用される。
451 Unavailable For Legal Reasons ～法的理由により利用不可～
政府によって検閲されたページなど法的理由により閲覧が禁止されている場合に表示されているステータスコード。
5xx サーバーエラー
サーバ側が原因によるシステムエラー発生時に返されるステータスコード。
500 Internal Server Error ～サーバ内部エラー～
サーバ内部にエラーが発生した場合に返されるエラー。
エラーの原因は多種多彩であるため、何が原因なのかはサーバ管理者にしかわからない。（推測できるものもあるが）
501 Not Implemented ～実装されていない～
実装されていないメソッドを検出した場合に表示されるステータスコード。
GETとPOSTのみサポートしているサーバにてCONNECTメソッドでリクエストを投げた場合に発生される。
405 Method Not Allowedと似ているが、
- 405はサーバ側で要求されたメソッドはわかるが使ってはダメ
- 501はサーバ側で要求されたメソッドが何なのかわからない
になるみたいです。
502 Bad Gateway ～不正なゲートウェイ～
基本的にプロキシに問題が発生し、正常に閲覧ができない場合に発生するステータスコード。
クライアント側で発生することは稀で、ほとんどがWebサーバが原因。
たとえば、nginxとphpの構成で、nginxとphpのオーナー・グループ設定がおかしい場合に発生したりする。
RFC 7231 Section 6.6.3
Nginx で「502 Bad Gateway」とか、なんだかエラーログがでるよって時
503 Service Unavailable ～サービス利用不可～
メンテナンス状態やサーバの負荷が高い場合に表示される。
例えば楽天のスーパーセールや人気のチケット販売が始まった瞬間にたくさんの人がアクセスされた場合とか。
こうなった場合は状況によるが、（余計悪化するけど）F5連打するか、負荷が下がるのを待つか、サーバー管理者のメンテ待ちしかない。
504 Gateway Timeout ～ゲートウェイタイムアウト～
502と似ているが、504はプロキシサーバからの応答が規定時間内に返ってこなかった場合に表示される。
サーバ⇔サーバ間側でエラーになっている場合が多く、クライアント側での発生することは稀。
例えばnginx・php構成上で、phpの処理が60秒以上の処理がかかった場合に発生したり。（fastcgi_read_timeout の修正で対応可能）
505 HTTP Version Not Supported ～サポートしていないHTTPバージョン～
名前通り、サポートされていないHTTPのバージョンでサーバに要求した場合に返答されるステータスコード。
例えば、HTTP/1.0しか許容しないサーバでHTTP/1.1で通信しようとした場合など。
506 Variant Also Negotiates ～内部配置上のエラー～
Transparent Content Negotiation in HTTPで定義されているステータスコード。
URLに返すコンテンツにて配置ミスなど内部エラーが発生した場合に返却される。
RFC 2295 Section 8.1
コンテンツネゴシエーション
507 Insufficient Storage ～容量不足～
WebDAV上でファイルを置こうとしたが、容量不足で置けなかった場合に返されるステータスコード。
508 Loop Detected ～ループ検出～
WebDAVのステータスコードである。サーバが「Depth: infinity」処理実施中に無限ループが発生した場合に返される。
509 Bandwidth Limit Exceeded ～帯域幅制限超過～
レンタルサーバなどで、転送量が上限に達した場合に返されるステータスコード。
実はこのステータスコードはRFCには明記されておらず、非公式。（結構使われているみたいですが。）
apacheの帯域制限で使われているからなのかな。
HTTPステータス「509 Bandwidth Limit Exceeded」に関して
510 Not Extended ～拡張できない～
An HTTP Extension Frameworkで定義されたステータスコードであり、HTTPヘッダの拡張ができない場合に返される。
上記は草案レベルであり、現在は使われてない（？）
511 Network Authentication Required ～ネットワークに対する認証が必要～
ネットワーク接続時に認証が必要になった場合に返されるステータスコード。
例えば、Wi-Fiスポットで外部ネットワーク接続申請をしないまま、外部URLへ接続しにいった際に表示されたりする。
