ietf-corpus

rfc-6585

Additional HTTP Status Codes

M. Nottingham, R. Fielding
date2012-04 streamIETF wgnon working group statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc6585 doi10.17487/RFC6585 errataview
This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]

updates

Extracted elements (25)

design-rationale §3

428 was designed to prevent the 'lost update' problem: a client GETs a resource, modifies it, and PUTs it back while a third party has modified the server state. By requiring conditional requests, the server ensures clients are working with correct copies.

http

design-rationale §6.1

511 is designed to mitigate problems caused by captive portals to software (especially non-browser agents) that expects a response from the intended server, not from intervening network infrastructure. It is not intended to encourage captive portal deployment.

http

design-rationale §6.1

Captive portals typically identify unknown clients by MAC address, block all traffic except TCP port 80, and redirect it to a login server. The 511 code allows non-browser clients to distinguish portal responses from origin responses.

http

design-rationale §1

These new status codes can be safely deployed by existing servers because clients treat unknown status codes as a generic error of the same class (e.g., 499 is treated as 400 if not recognized), per RFC 2616 Section 6.1.1.

http

interoperability-note §B

Non-browser HTTP applications such as WebDAV, CalDAV, widgets, software update clients, and Twitter clients can be adversely affected by captive portals, resulting in spurious errors and potentially content corruption. HTTP redirection does not solve this because many such applications follow redirects.

http

normative-requirement §4 SHOULD

429 response representations SHOULD include details explaining the rate-limiting condition, and MAY include a Retry-After header indicating how long to wait before making a new request.

http

normative-requirement §3 SHOULD

Responses using the 428 status code SHOULD explain how to resubmit the request successfully, e.g., by indicating that a conditional header such as If-Match is required.

http

normative-requirement §3 MUST NOT

Responses with the 428 status code MUST NOT be stored by a cache.

http

normative-requirement §4 MUST NOT

Responses with the 429 status code MUST NOT be stored by a cache.

http

normative-requirement §5 MUST NOT

Responses with the 431 status code MUST NOT be stored by a cache.

http

normative-requirement §6 MUST NOT

Responses with the 511 status code MUST NOT be stored by a cache.

http

normative-requirement §6 SHOULD

The 511 response representation SHOULD contain a link to a resource that allows the user to submit credentials (e.g., with an HTML form).

http

normative-requirement §6 SHOULD NOT

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.

http

normative-requirement §6 SHOULD NOT

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.

http

normative-requirement §5 SHOULD

When a single header field causes a 431 response, the response representation SHOULD specify which header field was too large.

http

protocol-element §3

428 Precondition Required indicates that the origin server requires the request to be conditional. Its typical use is to avoid the 'lost update' problem where a client modifies a resource that has since been changed by a third party.

http

protocol-element §4

429 Too Many Requests indicates that the user has sent too many requests in a given amount of time, i.e., rate limiting. The specification does not define how the server identifies the user or counts requests.

http

protocol-element §5

431 Request Header Fields Too Large indicates that the server is unwilling to process the request because its header fields are too large. It applies both when the total set of headers is too large and when a single header field is at fault.

http

protocol-element §6

511 Network Authentication Required indicates that the client needs to authenticate to gain network access. It is intended for use by intercepting proxies (captive portals), not origin servers.

http, security

registry §8

The HTTP Status Codes registry is updated with four new entries: 428 (Precondition Required), 429 (Too Many Requests), 431 (Request Header Fields Too Large), and 511 (Network Authentication Required), all referencing RFC 6585.

http, registry

security-consideration §7.1

428 is optional; clients cannot rely upon its use to prevent 'lost update' conflicts. Servers are not required to support or use it.

http, security

security-consideration §7.4

A 511 response will not come from the origin server, presenting security issues: an attacking intermediary may insert cookies into the original domain's namespace or observe cookies and HTTP authentication credentials sent by the user agent. These risks also apply to captive portals not using 511.

http, security

security-consideration §7.4

Captive portals using 511 on SSL/TLS connections (port 443) will generate a certificate error on the client, since the intercepting proxy cannot present a valid certificate for the origin server's domain.

http, security, tls

security-consideration §7.3

Servers are not required to use 431; when under attack, dropping connections or taking other steps may be more appropriate than sending 431 responses.

http, security

security-consideration §7.2

When a server is under attack or receiving a large number of requests from a single party, responding to each with 429 consumes resources. Servers are not required to use 429; dropping connections may be more appropriate.

http, security