[要約] RFC 6585は、追加のHTTPステータスコードを定義しています。その目的は、クライアントとサーバー間の通信において、より具体的なエラーや状態を伝えることです。
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 6585 Rackspace
Updates: 2616 R. Fielding
Category: Standards Track Adobe
ISSN: 2070-1721 April 2012
Additional HTTP Status Codes
追加のHTTPステータスコード
Abstract
概要
This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations.
このドキュメントでは、さまざまな一般的な状況に対する追加のハイパーテキスト転送プロトコル（HTTP）ステータスコードについて説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6585.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6585で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements ....................................................2
3. 428 Precondition Required .......................................2
4. 429 Too Many Requests ...........................................3
5. 431 Request Header Fields Too Large .............................4
6. 511 Network Authentication Required .............................4
7. Security Considerations .........................................6
8. IANA Considerations .............................................7
9. References ......................................................7
Appendix A. Acknowledgements .......................................9
Appendix B. Issues Raised by Captive Portals .......................9
This document specifies additional HTTP [RFC2616] status codes for a variety of common situations, to improve interoperability and avoid confusion when other, less precise status codes are used.
このドキュメントでは、さまざまな一般的な状況に対して追加のHTTP [RFC2616]ステータスコードを指定して、相互運用性を向上させ、他の精度の低いステータスコードが使用されている場合の混乱を回避しています。
Note that these status codes are optional; servers cannot be required to support them. However, because clients will treat unknown status codes as a generic error of the same class (e.g., 499 is treated as 400 if it is not recognized), they can be safely deployed by existing servers (see [RFC2616] Section 6.1.1 for more information).
これらのステータスコードはオプションです。サーバーはそれらをサポートする必要はありません。ただし、クライアントは不明なステータスコードを同じクラスの一般的なエラーとして処理するため（たとえば、認識されない場合、499は400として処理されます）、既存のサーバーによって安全にデプロイできます（[RFC2616]セクション6.1.1を参照）詳しくは）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The 428 status code indicates that the origin server requires the request to be conditional.
ステータスコード428は、オリジンサーバーがリクエストを条件付きにする必要があることを示しています。
Its typical use is to avoid the "lost update" problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict. By requiring requests to be conditional, the server can assure that clients are working with the correct copies.
その典型的な使用法は、クライアントがリソースの状態を取得し、それを変更し、サーバーにPUTする「失われた更新」の問題を回避することです。その間、第三者がサーバーの状態を変更し、競合が発生します。リクエストを条件付きにすることを要求することで、サーバーはクライアントが正しいコピーで作業していることを保証できます。
Responses using this status code SHOULD explain how to resubmit the request successfully. For example:
このステータスコードを使用した応答は、リクエストを正常に再送信する方法を説明する必要があります。例えば：
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>
Responses with the 428 status code MUST NOT be stored by a cache.
ステータスコード428のレスポンスは、キャッシュに保存してはなりません（MUST NOT）。
The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting").
429ステータスコードは、ユーザーが指定された時間内に送信したリクエストが多すぎることを示しています（「レート制限」）。
The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.
応答の表現には、条件を説明する詳細を含める必要があり（SHOULD）、新しい要求を行う前に待機する時間を示すRetry-Afterヘッダーを含めることができます（MAY）。
For example:
例えば：
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>
Note that this specification does not define how the origin server identifies the user, nor how it counts requests. For example, an origin server that is limiting request rates can do so based upon counts of requests on a per-resource basis, across the entire server, or even among a set of servers. Likewise, it might identify the user by its authentication credentials, or a stateful cookie.
この仕様では、オリジンサーバーがユーザーを識別する方法や、リクエストをカウントする方法は定義されていません。たとえば、リクエストレートを制限しているオリジンサーバーは、リソースごと、サーバー全体、または一連のサーバー間でのリクエスト数に基づいて制限することができます。同様に、認証資格情報またはステートフルCookieによってユーザーを識別する場合もあります。
Responses with the 429 status code MUST NOT be stored by a cache.
429ステータスコードの応答は、キャッシュに保存してはなりません（MUST NOT）。
The 431 status code indicates that the server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.
431ステータスコードは、ヘッダーフィールドが大きすぎるため、サーバーがリクエストを処理する意思がないことを示します。リクエストヘッダーフィールドのサイズを縮小した後、リクエストを再送信できます。
It can be used both when the set of request header fields in total is too large, and when a single header field is at fault. In the latter case, the response representation SHOULD specify which header field was too large.
リクエストヘッダーフィールドの合計が大きすぎる場合と、単一のヘッダーフィールドに問題がある場合の両方で使用できます。後者の場合、応答表現は、どのヘッダーフィールドが大きすぎるかを指定する必要があります（SHOULD）。
For example:
例えば：
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>
Responses with the 431 status code MUST NOT be stored by a cache.
ステータスコード431の応答は、キャッシュに保存してはなりません（MUST NOT）。
The 511 status code indicates that the client needs to authenticate to gain network access.
511ステータスコードは、クライアントがネットワークアクセスを得るために認証する必要があることを示します。
The response representation SHOULD contain a link to a resource that allows the user to submit credentials (e.g., with an HTML form).
応答表現には、ユーザーが資格情報を送信できるようにするリソースへのリンクが含まれている必要があります（例：HTMLフォームを使用）。
Note that the 511 response SHOULD NOT contain a challenge or the login interface itself, because browsers would show the login interface as being associated with the originally requested URL, which may cause confusion.
ブラウザーはログインインターフェースを最初にリクエストされたURLに関連付けられているものとして表示し、混乱を招く可能性があるため、511レスポンスにはチャレンジまたはログインインターフェース自体を含めないでください。
The 511 status SHOULD NOT be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.
511ステータスはオリジンサーバーによって生成されるべきではありません（SHOULD NOT）。これは、ネットワークへのアクセスを制御する手段として挿入されるプロキシを代行受信することによる使用を目的としています。
Responses with the 511 status code MUST NOT be stored by a cache.
ステータスコード511の応答は、キャッシュに保存してはなりません（MUST NOT）。
The 511 status code is designed to mitigate problems caused by "captive portals" to software (especially non-browser agents) that is expecting a response from the server that a request was made to, not the intervening network infrastructure. It is not intended to encourage deployment of captive portals -- only to limit the damage caused by them.
511ステータスコードは、介在するネットワークインフラストラクチャではなく、要求が行われたサーバーからの応答を予期しているソフトウェア（特に非ブラウザエージェント）への「キャプティブポータル」によって引き起こされる問題を軽減するように設計されています。キャプティブポータルの展開を促進することは目的としていません。それらによって引き起こされるダメージを制限するためだけです。
A network operator wishing to require some authentication, acceptance of terms, or other user interaction before granting access usually does so by identifying clients who have not done so ("unknown clients") using their Media Access Control (MAC) addresses.
アクセスを許可する前に、認証、条件の受け入れ、またはその他のユーザー操作を要求するネットワークオペレーターは、通常、メディアアクセス制御（MAC）アドレスを使用して、そうしていないクライアント（「不明なクライアント」）を識別します。
Unknown clients then have all traffic blocked, except for that on TCP port 80, which is sent to an HTTP server (the "login server") dedicated to "logging in" unknown clients, and of course traffic to the login server itself.
その後、不明なクライアントはすべてのトラフィックをブロックしますが、TCPポート80を除き、「ログイン」する不明なクライアント専用のHTTPサーバー（「ログインサーバー」）に送信されます。もちろん、ログインサーバー自体へのトラフィックも送信されます。
For example, a user agent might connect to a network and make the following HTTP request on TCP port 80:
たとえば、ユーザーエージェントがネットワークに接続し、TCPポート80で次のHTTPリクエストを行う場合があります。
GET /index.htm HTTP/1.1 Host: www.example.com
GET /index.htm HTTP / 1.1ホスト：www.example.com
Upon receiving such a request, the login server would generate a 511 response:
このような要求を受信すると、ログインサーバーは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>
Here, the 511 status code assures that non-browser clients will not interpret the response as being from the origin server, and the META HTML element redirects the user agent to the login server.
ここで、511ステータスコードは、ブラウザ以外のクライアントが応答をオリジンサーバーからのものとして解釈しないことを保証し、META HTML要素がユーザーエージェントをログインサーバーにリダイレクトします。
The 428 status code is optional; clients cannot rely upon its use to prevent "lost update" conflicts.
428ステータスコードはオプションです。クライアントは、「失われた更新」の競合を防ぐためにその使用に依存することはできません。
When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources.
サーバーが攻撃を受けている場合、または単一のパーティから非常に多数のリクエストを受信している場合、それぞれに429ステータスコードで応答するとリソースが消費されます。
Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.
したがって、サーバーは429ステータスコードを使用する必要はありません。リソースの使用を制限する場合は、接続をドロップするか、他の手順を実行する方が適切な場合があります。
Servers are not required to use the 431 status code; when under attack, it may be more appropriate to just drop connections, or take other steps.
サーバーは431ステータスコードを使用する必要はありません。攻撃を受けている場合は、接続を切断するか、他の手順を実行する方が適切な場合があります。
In common use, a response carrying the 511 status code will not come from the origin server indicated in the request's URL. This presents many security issues; e.g., an attacking intermediary may be inserting cookies into the original domain's name space, may be observing cookies or HTTP authentication credentials sent from the user agent, and so on.
一般的な用途では、511ステータスコードを含む応答は、リクエストのURLに示されているオリジンサーバーから送信されません。これには多くのセキュリティ問題があります。たとえば、攻撃の仲介者は、元のドメインの名前空間にCookieを挿入したり、ユーザーエージェントから送信されたCookieやHTTP認証資格情報を監視したりする場合があります。
However, these risks are not unique to the 511 status code; in other words, a captive portal that is not using this status code introduces the same issues.
ただし、これらのリスクは511ステータスコードに固有のものではありません。つまり、このステータスコードを使用していないキャプティブポータルでも同じ問題が発生します。
Also, note that captive portals using this status code on a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection (commonly, port 443) will generate a certificate error on the client.
また、Secure Socket Layer（SSL）またはTransport Layer Security（TLS）接続（通常、ポート443）でこのステータスコードを使用するキャプティブポータルは、クライアントで証明書エラーを生成することに注意してください。
The HTTP Status Codes registry has been updated with the following entries:
HTTPステータスコードレジストリが次のエントリで更新されました。
Value: 428 Description: Precondition Required Reference: [RFC6585]
値：428説明：前提条件が必要です参照：[RFC6585]
Value: 429 Description: Too Many Requests Reference: [RFC6585]
値：429説明：要求が多すぎます参照：[RFC6585]
Value: 431 Description: Request Header Fields Too Large Reference: [RFC6585]
値：431説明：リクエストヘッダーフィールドが大きすぎます参照：[RFC6585]
Value: 511 Description: Network Authentication Required Reference: [RFC6585]
値：511説明：ネットワーク認証が必要です参照：[RFC6585]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[CORS] van Kesteren, A., Ed., "Cross-Origin Resource Sharing", W3C Working Draft WD-cors-20100727, July 2010, <http://www.w3.org/TR/cors/>.
[CORS] van Kesteren、A。、編、「クロスオリジンリソースシェアリング」、W3CワーキングドラフトWD-cors-20100727、2010年7月、<http://www.w3.org/TR/cors/>。
[Favicon] Wikipedia, "Favicon", March 2012, <http://en.wikipedia.org/w/ index.php?title=Favicon&oldid=484627550>.
[ファビコン]ウィキペディア、「ファビコン」、2012年3月、<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.
[OAuth2.0] Hammer-Lahav、E.、Ed。、Recordon、D。、およびD. Hardt、「The OAuth 2.0 Authorization Protocol」、Work in Progress、2012年3月。
[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/>.
[P3P] Marchiori、M。、編、「The Platform for Privacy Preferences 1.0（P3P1.0）Specification」、W3C勧告REC-P3P-20020416、2002年4月、<http://www.w3.org/TR/ P3P />。
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.
[RFC4791] Daboo、C.、Desruisseaux、B。、およびL. Dusseault、「Calendaring Extensions to WebDAV（CalDAV）」、RFC 4791、2007年3月。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918] Dusseault、L.、Ed。、「Web Distributed Authoring and Versioning（WebDAV）のHTTP拡張機能」、RFC 4918、2007年6月。
[WIDGETS] Caceres, M., Ed., "Widget Packaging and XML Configuration", W3C Recommendation REC-widgets-20110927, September 2011, <http://www.w3.org/TR/widgets/>.
[ウィジェット] Caceres、M。、編、「ウィジェットのパッケージ化とXML構成」、W3C勧告REC-widgets-20110927、2011年9月、<http://www.w3.org/TR/widgets/>。
[WebFinger] WebFinger Project, "WebFingerProtocol (Draft)", January 2010, <http://code.google.com/p/webfinger/wiki/ WebFingerProtocol>.
[WebFinger] WebFingerプロジェクト、「WebFingerProtocol（Draft）」、2010年1月、<http://code.google.com/p/webfinger/wiki/ WebFingerProtocol>。
Thanks to Jan Algermissen and Julian Reschke for their suggestions and feedback.
Jan AlgermissenとJulian Reschkeの提案とフィードバックに感謝します。
Since clients cannot differentiate between a portal's response and that of the HTTP server that they intended to communicate with, a number of issues arise. The 511 status code is intended to help mitigate some of them.
クライアントは、ポータルの応答と、通信しようとしたHTTPサーバーの応答を区別できないため、いくつかの問題が発生します。 511ステータスコードは、それらの一部を軽減することを目的としています。
One example is the "favicon.ico" [Favicon] commonly used by browsers to identify the site being accessed. If the favicon for a given site is fetched from a captive portal instead of the intended site (e.g., because the user is unauthenticated), it will often "stick" in the browser's cache (most implementations cache favicons aggressively) beyond the portal session, so that it seems as if the portal's favicon has "taken over" the legitimate site.
1つの例は、アクセスされているサイトを識別するためにブラウザーによって一般的に使用される「favicon.ico」[ファビコン]です。特定のサイトのファビコンが、目的のサイトではなくキャプティブポータルからフェッチされた場合（たとえば、ユーザーが認証されていないため）、ポータルセッションを超えてブラウザーのキャッシュ（ほとんどの実装ではファビコンを積極的にキャッシュする）に保持されます。ポータルのファビコンが正当なサイトを「引き継いだ」かのように見えます。
Another browser-based issue comes about when the Platform for Privacy Preferences [P3P] is supported. Depending on how it is implemented, it's possible a browser might interpret a portal's response for the p3p.xml file as the server's, resulting in the privacy policy (or lack thereof) advertised by the portal being interpreted as applying to the intended site. Other Web-based protocols such as WebFinger [WebFinger], Cross-Origin Resource Sharing [CORS], and Open Authorization [OAuth2.0] may also be vulnerable to such issues.
Platform for Privacy Preferences [P3P]がサポートされている場合、別のブラウザベースの問題が発生します。実装方法によっては、ブラウザーがp3p.xmlファイルに対するポータルの応答をサーバーの応答として解釈する可能性があり、その結果、ポータルによってアドバタイズされたプライバシーポリシー（またはその欠如）は、意図したサイトに適用されるものとして解釈されます。 WebFinger [WebFinger]、クロスオリジンリソースシェアリング[CORS]、Open Authorization [OAuth2.0]などの他のWebベースのプロトコルも、このような問題に対して脆弱である可能性があります。
Although HTTP is most widely used with Web browsers, a growing number of non-browsing applications use it as a substrate protocol. For example, Web Distributed Authoring and Versioning (WebDAV) [RFC4918] and Calendaring Extensions to WebDAV (CalDAV) [RFC4791] both use HTTP as the basis (for remote authoring and calendaring, respectively). Using these applications from behind a captive portal can result in spurious errors being presented to the user, and might result in content corruption, in extreme cases.
HTTPはWebブラウザーで最も広く使用されていますが、非ブラウザーアプリケーションの多くがこれを基質プロトコルとして使用しています。たとえば、Web分散オーサリングとバージョン管理（WebDAV）[RFC4918]とWebDAVへのカレンダー拡張（CalDAV）[RFC4791]は両方とも、HTTPをベースとして使用します（それぞれリモートオーサリングとカレンダー用）。キャプティブポータルの背後からこれらのアプリケーションを使用すると、ユーザーに誤ったエラーが表示され、極端な場合にはコンテンツが破損する可能性があります。
Similarly, other non-browser applications using HTTP can be affected as well, e.g., widgets [WIDGETS], software updates, and other specialized software such as Twitter clients and the iTunes Music Store.
同様に、HTTPを使用する他のブラウザー以外のアプリケーションも影響を受ける可能性があります。たとえば、ウィジェット[ウィジェット]、ソフトウェアの更新、TwitterクライアントやiTunesミュージックストアなどのその他の専用ソフトウェアなどです。
It should be noted that it's sometimes believed that using HTTP redirection to direct traffic to the portal addresses these issues. However, since many of these uses "follow" redirects, this is not a good solution.
HTTPリダイレクトを使用してトラフィックをポータルに転送すると、これらの問題に対処できると考えられていることに注意してください。ただし、これらの多くは「フォロー」リダイレクトを使用するため、これは適切な解決策ではありません。
Authors' Addresses
著者のアドレス
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
ロイT.フィールディングAdobe Systems Incorporated 345 Park Ave. San Jose、CA 95110 USA
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/