idnits 2.17.1
draft-nottingham-http-new-status-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([2], [1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
-- The draft header indicates that this document updates RFC2616, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC2616, updated by this document, for
RFC5378 checks: 1997-10-16)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 31, 2011) is 4562 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Nottingham
3 Internet-Draft Rackspace
4 Updates: 2616 (if approved) R. Fielding
5 Intended status: Standards Track Adobe
6 Expires: May 3, 2012 October 31, 2011
8 Additional HTTP Status Codes
9 draft-nottingham-http-new-status-03
11 Abstract
13 This document specifies additional HyperText Transfer Protocol (HTTP)
14 status codes for a variety of common situations.
16 Editorial Note (To be removed by RFC Editor before publication)
18 Distribution of this document is unlimited. Although this is not a
19 work item of the HTTPbis Working Group, comments should be sent to
20 the Hypertext Transfer Protocol (HTTP) mailing list at
21 ietf-http-wg@w3.org [1], which may be joined by sending a message
22 with subject "subscribe" to ietf-http-wg-request@w3.org [2].
24 Discussions of the HTTPbis Working Group are archived at
25
This request is required to be conditional; 112 try using "If-Match".
113 114 116 Responses with the 428 status code MUST NOT be stored by a cache. 118 4. 429 Too Many Requests 120 This status code indicates that the user has sent too many requests 121 in a given amount of time ("rate limiting"). 123 The response representations SHOULD include details explaining the 124 condition, and MAY include a Retry-After header indicating how long 125 to wait before making a new request. 127 For example: 129 HTTP/1.1 429 Too Many Requests 130 Content-Type: text/html 131 Retry-After: 3600 133 134 135I only allow 50 requests per hour to this Web site per 140 logged in user. Try again soon.
141 142 144 Note that this specification does not define how the origin server 145 identifies the user, nor how it counts requests. For example, an 146 origin server that is limiting request rates can do so based upon 147 counts of requests on a per-resource basis, across the entire server, 148 or even among a set of servers. Likewise, it might identify the user 149 by its authentication credentials, or a stateful cookie. 151 Responses with the 429 status code MUST NOT be stored by a cache. 153 5. 431 Request Header Fields Too Large 155 This status code indicates that the server is unwilling to process 156 the request because its header fields are too large. The request MAY 157 be resubmitted after reducing the size of the request header fields. 159 It can be used both when the set of request header fields in total 160 are too large, and when a single header field is at fault. In the 161 latter case, the response representation SHOULD specify which header 162 field was too large. 164 For example: 166 HTTP/1.1 431 Request Header Fields Too Large 167 Content-Type: text/html 169 170 171The "Example" header was too large.
176 177 179 Responses with the 431 status code MUST NOT be stored by a cache. 181 6. 511 Network Authentication Required 183 This status code indicates that the client needs to authenticate to 184 gain network access. 186 The response representation SHOULD indicate how to do this; e.g., 187 with an HTML form for submitting credentials. 189 The 511 status SHOULD NOT be generated by origin servers; it is 190 intended for use by intercepting proxies that are interposed as a 191 means of controlling access to the network. 193 Responses with the 511 status code MUST NOT be stored by a cache. 195 6.1. The 511 Status Code and Captive Portals 197 A network operator wishing to require some authentication, acceptance 198 of terms or other user interaction before granting access usually 199 does so by identify clients who have not done so ("unknown clients") 200 using their MAC addresses. 202 Unknown clients then have all traffic blocked, except for that on TCP 203 port 80, which is sent to a HTTP server (the "login server") 204 dedicated to "logging in" unknown clients, and of course traffic to 205 the login server itself. 207 For example, a user agent might connect to a network and make the 208 following HTTP request on TCP port 80: 210 GET /index.htm HTTP/1.1 211 Host: www.example.com 212 Upon receiving such a request, the login server would generate a 511 213 response: 215 HTTP/1.1 511 Network Authentication Required 216 Content-Type: text/html 218 219 220You need to 226 authenticate with the local network in order to gain 227 access.
228 229 231 Here, the 511 status code assures that non-browser clients will not 232 interpret the response as being from the origin server, and the META 233 HTML element redirects the user agent to the login server. 235 Note that the 511 response can itself contain the login interface, 236 but it may not be desirable to do so, because browsers would show the 237 login interface as being associated with the originally requested 238 URL, which may cause confusion. 240 7. Security Considerations 242 7.1. 428 Precondition Required 244 The 428 status code is optional; clients cannot rely upon its use to 245 prevent "lost update" conflicts. 247 7.2. 429 Too Many Requests 249 Servers are not required to use the 429 status code; when limiting 250 resource usage, it may be more appropriate to just drop connections, 251 or take other steps. 253 7.3. 431 Request Header Fields Too Large 255 Servers are not required to use the 431 status code; when under 256 attack, it may be more appropriate to just drop connections, or take 257 other steps. 259 7.4. 511 Network Authentication Required 261 In common use, a response carrying the 511 status code will not come 262 from the origin server indicated in the request's URL. This presents 263 many security issues; e.g., an attacking intermediary may be 264 inserting cookies into the original domain's name space, may be 265 observing cookies or HTTP authentication credentials sent from the 266 user agent, and so on. 268 However, these risks are not unique to the 511 status code; in other 269 words, a captive portal that is not using this status code introduces 270 the same issues. 272 8. IANA Considerations 274 The HTTP Status Codes Registry should be updated with the following 275 entries: 277 o Code: 428 278 o Description: Precondition Required 279 o Specification: [ this document ] 281 o Code: 429 282 o Description: Too Many Requests 283 o Specification: [ this document ] 285 o Code: 431 286 o Description: Request Header Fields Too Large 287 o Specification: [ this document ] 289 o Code: 511 290 o Description: Network Authentication Required 291 o Specification: [ this document ] 293 9. References 295 9.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 301 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 302 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 304 9.2. Informative References 306 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 307 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 308 March 2007. 310 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 311 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 313 URIs 315 [1]