インターネットエンジニアリングタスクフォース（IETF）

M. Nottingham

Request for Comments: 6585

Rackspace

更新: 2616

R. Fielding

カテゴリ: 標準トラック

Adobe

ISSN: 2070-1721

2012年4月

追加のHTTPステータスコード

概要

この文書は、さまざまな一般的な状況に対する追加のHyperText Transfer Protocol (HTTP) ステータスコードを定めます。

このメモのステータス

本書はインターネット標準トラックの文書です。

本書はインターネットエンジニアリングタスクフォース（IETF）の成果物です。本書はIETFコミュニティのコンセンサスを示します。本書は公開レビューを受け、インターネットエンジニアリング運営グループ（IESG）によって公開が承認されています。インターネット標準に関する詳細は RFC 5741 のセクション 2 を参照してください。

本書の現在の状況、訂正（errata）、およびフィードバックの方法に関する情報は http://www.rfc-editor.org/info/rfc6585 で入手できます。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. 序論
2. 要件
3. 428 前提条件が必要
4. 429 リクエストが多すぎます
5. 431 リクエストヘッダーフィールドが大きすぎます
6. 511 ネットワーク認証が必要
7. セキュリティに関する考慮事項
8. IANAに関する考慮事項
9. 参考文献
Appendix A. 謝辞
Appendix B. キャプティブポータルによって提起された問題
著者の連絡先

1. 序論

この文書は、さまざまな一般的な状況に対して追加の HTTP [RFC2616] ステータスコードを定め、相互運用性を向上させ、他のより曖昧なステータスコードが使用された場合の混乱を避けることを目的としています。

これらのステータスコードは任意であり、サーバーに対してサポートを強制することはできない点に注意してください。しかし、クライアントは未知のステータスコードを同じクラスの一般的なエラーとして扱う（例えば、499 は認識されない場合 400 として扱われる）ため、既存のサーバーでも安全に導入できます（詳細は [RFC2616] のセクション 6.1.1 を参照してください）。

2. 要件

本書で使用されるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、[RFC2119] に記載されているとおりに解釈されます。

3. 428 前提条件が必要

428 ステータスコードは、オリジンサーバーがリクエストに対して条件付きであることを要求していることを示します。

典型的な用途は、クライアントがリソースの状態をGETし、それを変更してPUTでサーバーに戻す間に第三者がサーバー上の状態を変更して競合が発生する「ロストアップデート」問題を回避することです。サーバーがリクエストを条件付きにすることで、クライアントが正しいコピーで作業していることを確認できます。

このステータスコードを使用するレスポンスは、リクエストを再送する方法を説明するべきです。例えば：

HTTP/1.1 428 Precondition Required
Content-Type: text/html

<html>
   <head>
      <title>Precondition Required</title>
   </head>
   <body>
      <h1>Precondition Required</h1>
      <p>This request is required to be conditional; 
      try using "If-Match".</p>
   </body>
</html>

428 ステータスコードを持つレスポンスは、キャッシュに保存してはなりません。

4. 429 リクエストが多すぎます

429 ステータスコードは、ある一定期間内にユーザーがあまりにも多くのリクエストを送信したこと（「レート制限」）を示します。

レスポンス表現は、状況を説明する詳細を含めるべきであり、再リクエストまでの待機時間を示す Retry-After ヘッダーを含めてもよいです。

例えば：

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600

<html>
   <head>
      <title>Too Many Requests</title>
   </head>
   <body>
      <h1>Too Many Requests</h1>
      <p>I only allow 50 requests per hour to this Web site per
         logged in user.  Try again soon.</p>
   </body>
</html>

この仕様は、オリジンサーバーがユーザーをどのように識別するか、またどのようにリクエストをカウントするかを定義するものではないことに注意してください。例えば、リクエストレートを制限するオリジンサーバーは、リソース単位、サーバー全体、あるいはサーバー群にわたってカウントすることができます。同様に、ユーザーは認証資格情報やステートフルなクッキーによって識別されるかもしれません。

429 ステータスコードを持つレスポンスは、キャッシュに保存してはなりません。

5. 431 リクエストヘッダーフィールドが大きすぎます

431 ステータスコードは、サーバーがリクエストのヘッダーフィールドが大きすぎるためリクエストの処理を拒否することを示します。リクエストヘッダーフィールドのサイズを縮小した後にリクエストを再送信してもよいです。

これは、リクエストヘッダーフィールドの合計が大きすぎる場合にも、単一のヘッダーフィールドが原因の場合にも使用できます。後者の場合、レスポンス表現はどのヘッダーフィールドが大きすぎたかを指定するべきです。

例えば：

HTTP/1.1 431 Request Header Fields Too Large
Content-Type: text/html

<html>
   <head>
      <title>Request Header Fields Too Large</title>
   </head>
   <body>
      <h1>Request Header Fields Too Large</h1>
      <p>The "Example" header was too large.</p>
   </body>
</html>

431 ステータスコードを持つレスポンスは、キャッシュに保存してはなりません。

6. 511 ネットワーク認証が必要

511 ステータスコードは、クライアントがネットワークアクセスを得るために認証する必要があることを示します。

レスポンス表現は、ユーザーが資格情報を送信できるリソースへのリンク（例えば HTML フォーム）を含むべきです。

511 レスポンスはチャレンジやログインインターフェース自体を含むべきではありません。ブラウザはログインインターフェースを元の要求された URL に関連付けて表示し、混乱を招く可能性があるためです。

511 ステータスはオリジンサーバーによって生成されるべきではありません。これはネットワークへのアクセスを制御するために介在するインターセプティングプロキシによって使用されることを意図しています。

511 ステータスコードを持つレスポンスは、キャッシュに保存してはなりません。

6.1. 511 ステータスコードとキャプティブポータル

511 ステータスコードは、ソフトウェア（特に非ブラウザのエージェント）が、要求したサーバーからのレスポンスを期待している場合に、介在するネットワークインフラが返すレスポンスによって引き起こされる問題を軽減するために設計されています。これはキャプティブポータルの導入を奨励するものではなく、それによって生じる被害を制限することを目的としています。

ネットワーク管理者が認証や利用規約の承諾、その他のユーザー操作を要求する場合、通常は Media Access Control (MAC) アドレスを使ってまだそれらを行っていないクライアント（「不明なクライアント」）を識別します。

不明なクライアントはすべてのトラフィックがブロックされますが、TCP ポート 80 のトラフィックのみが HTTP サーバー（「ログインサーバー」）に送られ、不明なクライアントの「ログイン」を扱うことになります。もちろんログインサーバー自身へのトラフィックは除外されます。

例えば、ユーザーエージェントがネットワークに接続して TCP ポート 80 で次の HTTP リクエストを行うかもしれません：

GET /index.htm HTTP/1.1
Host: www.example.com

そのようなリクエストを受け取ると、ログインサーバーは 511 レスポンスを生成します：

HTTP/1.1 511 Network Authentication Required
Content-Type: text/html

<html>
   <head>
      <title>Network Authentication Required</title>
      <meta http-equiv="refresh" 
            content="0; url=https://login.example.net/">
   </head>
   <body>
      <p>You need to <a href="https://login.example.net/">
      authenticate with the local network</a> in order to gain 
      access.</p>
   </body>
</html>

ここで、511 ステータスコードは非ブラウザクライアントがレスポンスをオリジンサーバーからのものと誤解しないようにし、META HTML 要素はユーザーエージェントをログインサーバーへリダイレクトします。

7. セキュリティに関する考慮事項

7.1. 428 前提条件が必要

428 ステータスコードは任意であり、クライアントは「ロストアップデート」競合を防ぐためにその使用を前提とすることはできません。

7.2. 429 リクエストが多すぎます

サーバーが攻撃を受けているか、単一の当事者から非常に大量のリクエストを受け取っている場合、各リクエストに対して 429 ステータスで応答することはリソースを消費します。

したがって、サーバーは 429 ステータスコードを使用する義務はありません。リソースの使用を制限する際には、単に接続を切断するなどの方が適切な場合があります。

7.3. 431 リクエストヘッダーフィールドが大きすぎます

サーバーは 431 ステータスコードを使用する義務はありません。攻撃を受けている場合、単に接続を切断するなどの方が適切な場合があります。

7.4. 511 ネットワーク認証が必要

一般的に、511 ステータスコードを含むレスポンスは要求の URL に示されたオリジンサーバーからのものではありません。これは多くのセキュリティ問題を引き起こします。例えば、攻撃的な仲介者が元のドメインの名前空間にクッキーを挿入したり、ユーザーエージェントから送信されるクッキーや HTTP 認証資格情報を観察したりする可能性があります。

しかし、これらのリスクは 511 ステータスコードに特有のものではありません。言い換えれば、このステータスコードを使用していないキャプティブポータルも同じ問題を引き起こします。

また、SSL/TLS 接続（通常はポート 443）でこのステータスコードを使用するキャプティブポータルは、クライアント側で証明書エラーを発生させることに注意してください。

8. IANAに関する考慮事項

HTTP ステータスコードのレジストリは、次のエントリで更新されました：

Value: 428
Description: Precondition Required
Reference: [RFC6585]

Value: 429
Description: Too Many Requests
Reference: [RFC6585]

Value: 431
Description: Request Header Fields Too Large
Reference: [RFC6585]

Value: 511
Description: Network Authentication Required
Reference: [RFC6585]

9. 参考文献

9.1. 規範的参考文献

[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2616]: Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.

9.2. 参考資料（情報）

[CORS]: van Kesteren, A., Ed., “Cross-Origin Resource Sharing”, W3C Working Draft WD-cors-20100727, July 2010, <http://www.w3.org/TR/cors/>.
[Favicon]: Wikipedia, “Favicon”, March 2012, <http://en.wikipedia.org/w/index.php?title=Favicon&oldid=484627550>.
[OAuth2.0]: Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol”, Work in Progress, March 2012.
[P3P]: Marchiori, M., Ed., “The Platform for Privacy Preferences 1.0 (P3P1.0) Specification”, W3C Recommendation REC-P3P-20020416, April 2002, <http://www.w3.org/TR/P3P/>.
[RFC4791]: Daboo, C., Desruisseaux, B., and L. Dusseault, “Calendaring Extensions to WebDAV (CalDAV)”, RFC 4791, March 2007.
[RFC4918]: Dusseault, L., Ed., “HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)”, RFC 4918, June 2007.
[WIDGETS]: Caceres, M., Ed., “Widget Packaging and XML Configuration”, W3C Recommendation REC-widgets-20110927, September 2011, <http://www.w3.org/TR/widgets/>.
[WebFinger]: WebFinger Project, “WebFingerProtocol (Draft)”, January 2010, <http://code.google.com/p/webfinger/wiki/WebFingerProtocol>.

Appendix A. 謝辞

Jan Algermissen と Julian Reschke に提案とフィードバックを感謝します。

Appendix B. キャプティブポータルによって提起された問題

クライアントはポータルのレスポンスと意図した HTTP サーバーのレスポンスを区別できないため、多くの問題が発生します。511 ステータスコードはそれらの一部を軽減することを目的としています。

一例はブラウザがサイトを識別するために一般的に使用する "favicon.ico" [Favicon] です。特定サイトの favicon が意図したサイトではなくキャプティブポータルから取得された場合（例えばユーザーが未認証であるため）、ほとんどの実装が favicon を積極的にキャッシュするため、ポータルのセッションを超えてブラウザのキャッシュに残り、ポータルの favicon が正当なサイトを「乗っ取った」ように見えることがあります。

別のブラウザベースの問題は、Platform for Privacy Preferences [P3P] がサポートされている場合に起こります。実装方法によっては、ポータルの p3p.xml に対するレスポンスをサーバーのものと解釈してしまい、ポータルが提示するプライバシーポリシー（またはその不在）が意図したサイトに適用されると解釈される可能性があります。WebFinger [WebFinger]、Cross-Origin Resource Sharing [CORS]、および Open Authorization [OAuth2.0] のような他の Web ベースのプロトコルも同様の問題に脆弱であり得ます。

HTTP は主に Web ブラウザで使用されていますが、非ブラウザアプリケーションでの使用も増えています。例えば、Web Distributed Authoring and Versioning (WebDAV) [RFC4918] や Calendaring Extensions to WebDAV (CalDAV) [RFC4791] はそれぞれリモート編集やカレンダリングのために HTTP を基盤として使用します。これらのアプリケーションをキャプティブポータルの背後から使用すると、ユーザーに誤ったエラーが表示されたり、極端な場合にはコンテンツの破損が発生する可能性があります。

同様に、ウィジェット [WIDGETS]、ソフトウェアアップデート、Twitter クライアントや iTunes Music Store のようなその他の特殊なソフトウェアなど、HTTP を使用する他の非ブラウザアプリケーションも影響を受ける可能性があります。

HTTP リダイレクトを使ってトラフィックをポータルに誘導することがこれらの問題を解決すると信じられていることがありますが、多くの利用方法がリダイレクトを「追跡」するため、これは良い解決策ではありません。

著者の連絡先

Mark Nottingham
Rackspace
Email: mnot@mnot.net
URI: http://www.mnot.net/

Roy T. Fielding
Adobe Systems Incorporated
345 Park Ave.
San Jose, CA 95110
USA
Email: fielding@gbiv.com
URI: http://roy.gbiv.com/