Adds 4xx Client Error class status codes descriptions from latest standards

contents/codes/400.md

@@ -2,6 +2,15 @@
 set: 4
 code: 400
 title: Bad Request
+references:
+    "Rails HTTP Status Symbol": "bad_request"
 ---
 
-This is the contents of the 400 status code
+The 400 (Bad Request) status code indicates that the server cannot or will not
+process the request due to something that is perceived to be a client error
+(e.g., malformed request syntax, invalid request message framing, or deceptive
+request routing).
+
+Source: [RFC7231 Section 6.5.1][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.1>

contents/codes/401.md

@@ -2,6 +2,26 @@
 set: 4
 code: 401
 title: Unauthorized
+references:
+    "Rails HTTP Status Symbol": ":unauthorized"
 ---
 
-This is the contents of the 401 status code
+The 401 (Unauthorized) status code indicates that the request has not been
+applied because it lacks valid authentication credentials for the target
+resource. The server generating a 401 response MUST send a WWW-Authenticate
+header field ([RFC7235 Section 4.1][2]) containing at least one challenge
+applicable to the target resource.
+
+If the request included authentication credentials, then the 401 response
+indicates that authorization has been refused for those credentials. The user
+agent MAY repeat the request with a new or replaced Authorization header field
+([RFC7235 Section 4.2][3]). If the 401 response contains the same challenge as
+the prior response, and the user agent has already attempted authentication at
+least once, then the user agent SHOULD present the enclosed representation to
+the user, since it usually contains relevant diagnostic information.
+
+Source: [RFC7235 Section 3.1][1]
+
+[1]: <http://tools.ietf.org/html/rfc7235#section-3.1>
+[2]: <http://tools.ietf.org/html/rfc7235#section-4.1>
+[3]: <http://tools.ietf.org/html/rfc7235#section-4.2>

contents/codes/402.md

@@ -2,6 +2,12 @@
 set: 4
 code: 402
 title: Payment Required
+references:
+    "Rails HTTP Status Symbol": ":payment_required"
 ---
 
-This is the contents of the 402 status code
+The 402 (Payment Required) status code is reserved for future use.
+
+Source: [RFC7231 Section 6.5.2][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.2>

contents/codes/403.md

@@ -2,6 +2,24 @@
 set: 4
 code: 403
 title: Forbidden
+references:
+    "Rails HTTP Status Symbol": ":forbidden"
 ---
 
-This is the contents of the 403 status code
+The 403 (Forbidden) status code indicates that the server understood the request
+but refuses to authorize it. A server that wishes to make public why the request
+has been forbidden can describe that reason in the response payload (if any).
+
+If authentication credentials were provided in the request, the server considers
+them insufficient to grant access. The client SHOULD NOT automatically repeat
+the request with the same credentials. The client MAY repeat the request with
+new or different credentials. However, a request might be forbidden for reasons
+unrelated to the credentials.
+
+An origin server that wishes to "hide" the current existence of a forbidden
+target resource MAY instead respond with a status code of
+[404 (Not Found)](/404).
+
+Source: [RFC7231 Section 6.5.3][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.3>

contents/codes/404.md

@@ -2,6 +2,22 @@
 set: 4
 code: 404
 title: Not Found
+references:
+    "Rails HTTP Status Symbol": ":not_found"
 ---
 
-This is the contents of the 404 status code
+The 404 (Not Found) status code indicates that the origin server did not find a
+current representation for the target resource or is not willing to disclose
+that one exists. A 404 status code does not indicate whether this lack of
+representation is temporary or permanent; the [410 (Gone)](/410) status code is
+preferred over 404 if the origin server knows, presumably through some
+configurable means, that the condition is likely to be permanent.
+
+A 404 response is cacheable by default; i.e., unless otherwise indicated by the
+method definition or explicit cache controls
+(see [Section 4.2.2 of RFC7234][2]).
+
+Source: [RFC7231 6.5.4][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.4>
+[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

contents/codes/405.md

@@ -2,6 +2,19 @@
 set: 4
 code: 405
 title: Method Not Allowed
+references:
+    "Rails HTTP Status Symbol": ":method_not_allowed"
 ---
 
-This is the contents of the 405 status code
+The 405 (Method Not Allowed) status code indicates that the method received in
+the request-line is known by the origin server but not supported by the target
+resource. The origin server MUST generate an Allow header field in a 405
+response containing a list of the target resource's currently supported methods.
+
+A 405 response is cacheable by default; i.e., unless otherwise indicated by the
+method definition or explicit cache controls (see [Section 4.2.2 of RFC7234][2]).
+
+Source: [RFC7231 Section 6.5.5][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.5>
+[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

contents/codes/406.md

@@ -2,6 +2,25 @@
 set: 4
 code: 406
 title: Not Acceptable
+references:
+    "Rails HTTP Status Symbol": ":not_acceptable"
 ---
 
-This is the contents of the 406 status code
+The 406 (Not Acceptable) status code indicates that the target resource does not
+have a current representation that would be acceptable to the user agent,
+according to the proactive negotiation header fields received in the request
+([RFC7231 Section 5.3][2]), and the server is unwilling to supply a default
+representation.
+
+The server SHOULD generate a payload containing a list of available
+representation characteristics and corresponding resource identifiers from which
+the user or user agent can choose the one most appropriate. A user agent MAY
+automatically select the most appropriate choice from that list. However, this
+specification does not define any standard for such automatic selection, as
+described in [RFC7231 Section 6.4.1][3].
+
+Source: [RFC7231 Section 6.5.6][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.6>
+[2]: <http://tools.ietf.org/html/rfc7231#section-5.3>
+[3]: <http://tools.ietf.org/html/rfc7231#section-6.4.1>

contents/codes/407.md

@@ -2,6 +2,20 @@
 set: 4
 code: 407
 title: Proxy Authentication Required
+references:
+    "Rails HTTP Status Symbol": ":proxy_authentication_required"
 ---
 
-This is the contents of the 407 status code
+The 407 (Proxy Authentication Required) status code is similar to
+[401 (Unauthorized)](/401), but it indicates that the client needs to
+authenticate itself in order to use a proxy.  The proxy MUST send a
+Proxy-Authenticate header field ([Section 4.3][2]) containing a challenge
+applicable to that proxy for the target resource.  The client MAY repeat the
+request with a new or replaced Proxy-Authorization header field
+([Section 4.4][3]).
+
+Source: [RFC7235 Section 3.2][1]
+
+[1]: <http://tools.ietf.org/html/rfc7235#section-3.2>
+[2]: <http://tools.ietf.org/html/rfc7235#section-4.3>
+[3]: <http://tools.ietf.org/html/rfc7235#section-4.4>

contents/codes/408.md

@@ -2,6 +2,18 @@
 set: 4
 code: 408
 title: Request Timeout
+references:
+    "Rails HTTP Status Symbol": ":request_timeout"
 ---
 
-This is the contents of the 408 status code
+The 408 (Request Timeout) status code indicates that the server did not receive
+a complete request message within the time that it was prepared to wait. A
+server SHOULD send the "close" connection option ([Section 6.1 of RFC7230][2])
+in the response, since 408 implies that the server has decided to close the
+connection rather than continue waiting. If the client has an outstanding
+request in transit, the client MAY repeat that request on a new connection.
+
+Source: [RFC7231 Section 6.5.7][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.7>
+[2]: <http://tools.ietf.org/html/rfc7230#section-6.1>

contents/codes/409.md

@@ -2,6 +2,23 @@
 set: 4
 code: 409
 title: Conflict
+references:
+    "Rails HTTP Status Symbol": ":conflict"
 ---
 
-This is the contents of the 409 status code
+The 409 (Conflict) status code indicates that the request could not be completed
+due to a conflict with the current state of the target resource. This code is
+used in situations where the user might be able to resolve the conflict and
+resubmit the request. The server SHOULD generate a payload that includes enough
+information for a user to recognize the source of the conflict.
+
+Conflicts are most likely to occur in response to a PUT request. For example, if
+versioning were being used and the representation being PUT included changes to
+a resource that conflict with those made by an earlier (third-party) request,
+the origin server might use a 409 response to indicate that it can't complete
+the request. In this case, the response representation would likely contain
+information useful for merging the differences based on the revision history.
+
+Source: [RFC7231 Section 6.5.8][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.8>

contents/codes/410.md

@@ -2,6 +2,30 @@
 set: 4
 code: 410
 title: Gone
+references:
+    "Rails HTTP Status Symbol": ":gone"
 ---
 
-This is the contents of the 410 status code
+The 410 (Gone) status code indicates that access to the target resource is no
+longer available at the origin server and that this condition is likely to be
+permanent. If the origin server does not know, or has no facility to determine,
+whether or not the condition is permanent, the status code
+[404 (Not Found)](/404) ought to be used instead.
+
+The 410 response is primarily intended to assist the task of web maintenance by
+notifying the recipient that the resource is intentionally unavailable and that
+the server owners desire that remote links to that resource be removed. Such an
+event is common for limited-time, promotional services and for resources
+belonging to individuals no longer associated with the origin server's site. It
+is not necessary to mark all permanently unavailable resources as "gone" or to
+keep the mark for any length of time -- that is left to the discretion of the
+server owner.
+
+A 410 response is cacheable by default; i.e., unless otherwise indicated by the
+method definition or explicit cache controls
+(see [Section 4.2.2 of RFC7234][2]).
+
+Source: [RFC7231 Section 6.5.9][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.9>
+[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

contents/codes/411.md

@@ -2,6 +2,17 @@
 set: 4
 code: 411
 title: Length Required
+references:
+    "Rails HTTP Status Symbol": ":length_required"
 ---
 
-This is the contents of the 411 status code
+The 411 (Length Required) status code indicates that the server refuses to
+accept the request without a defined Content-Length
+([Section 3.3.2 of RFC7230][2]). The client MAY repeat the request if it adds a
+valid Content-Length header field containing the length of the message body in
+the request message.
+
+Source: [RFC7231 Section 6.5.10][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.10>
+[2]: <http://tools.ietf.org/html/rfc7230#section-3.3.2>

contents/codes/412.md

@@ -2,6 +2,17 @@
 set: 4
 code: 412
 title: Precondition Failed
+references:
+    "Rails HTTP Status Symbol": ":precondition_failed"
 ---
 
-This is the contents of the 412 status code
+The 412 (Precondition Failed) status code indicates that one or more conditions
+given in the request header fields evaluated to false when tested on the server.
+This response code allows the client to place preconditions on the current
+resource state (its current representations and metadata) and, thus, prevent the
+request method from being applied if the target resource is in an unexpected
+state.
+
+Source: [RFC7232 Section 4.2][1]
+
+[1]: <http://tools.ietf.org/html/rfc7232#section-4.2>

contents/codes/413.md

@@ -1,7 +1,20 @@
 ---
 set: 4
 code: 413
-title: Request Entity Too Large
+title: Payload Too Large
+references:
+    "Rails HTTP Status Symbol": ":request_entity_too_large"
 ---
 
-This is the contents of the 413 status code
+The 413 (Payload Too Large) status code indicates that the server is refusing
+to process a request because the request payload is larger than the server is
+willing or able to process. The server MAY close the connection to prevent the
+client from continuing the request.
+
+If the condition is temporary, the server SHOULD generate a Retry-After header
+field to indicate that it is temporary and after what time the client MAY try
+again.
+
+Source: [RFC7231 Section 6.5.11][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.11>

contents/codes/414.md

@@ -2,6 +2,25 @@
 set: 4
 code: 414
 title: Request-URI Too Long
+references:
+    "Rails HTTP Status Symbol": ":request_uri_too_long"
 ---
 
-This is the contents of the 414 status code
+The 414 (URI Too Long) status code indicates that the server is refusing to
+service the request because the request-target ([Section 5.3 of RFC7230][2]) is
+longer than the server is willing to interpret. This rare condition is only
+likely to occur when a client has improperly converted a POST request to a GET
+request with long query information, when the client has descended into a "black
+hole" of redirection (e.g., a redirected URI prefix that points to a suffix of
+itself) or when the server is under attack by a client attempting to exploit
+potential security holes.
+
+A 414 response is cacheable by default; i.e., unless otherwise indicated by the
+method definition or explicit cache controls
+(see [Section 4.2.2 of RFC7234][3]).
+
+Source: [RFC7231 Section 6.5.12][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.12>
+[2]: <http://tools.ietf.org/html/rfc7231#section-5.3>
+[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

contents/codes/415.md

@@ -2,6 +2,16 @@
 set: 4
 code: 415
 title: Unsupported Media Type
+references:
+    "Rails HTTP Status Symbol": ":unsupported_media_type"
 ---
 
-This is the contents of the 415 status code
+The 415 (Unsupported Media Type) status code indicates that the origin server is
+refusing to service the request because the payload is in a format not supported
+by this method on the target resource. The format problem might be due to the
+request's indicated Content-Type or Content-Encoding, or as a result of
+inspecting the data directly.
+
+Source: [RFC7231 Section 6.5.13][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.13>

contents/codes/416.md

@@ -2,6 +2,41 @@
 set: 4
 code: 416
 title: Requested Range Not Satisfiable
+references:
+    "Rails HTTP Status Symbol": ":requested_range_not_satisfiable"
 ---
 
-This is the contents of the 416 status code
+The 416 (Range Not Satisfiable) status code indicates that none of the ranges in
+the request's Range header field ([RFC7233 Section 3.1][2]) overlap the current
+extent of the selected resource or that the set of ranges requested has been
+rejected due to invalid ranges or an excessive request of small or overlapping
+ranges.
+
+For byte ranges, failing to overlap the current extent means that the
+first-byte-pos of all of the byte-range-spec values were greater than the
+current length of the selected representation. When this status code is
+generated in response to a byte-range request, the sender SHOULD generate a
+Content-Range header field specifying the current length of the selected
+representation ([RFC7233 Section 4.2][3]).
+
+For example:
+
+```
+HTTP/1.1 416 Range Not Satisfiable
+Date: Fri, 20 Jan 2012 15:41:54 GMT
+Content-Range: bytes */47022
+```
+
+Note: Because servers are free to ignore Range, many implementations will simply
+respond with the entire selected representation in a [200 (OK)](/200) response.
+That is partly because most clients are prepared to receive a [200 (OK)](/200)
+to complete the task (albeit less efficiently) and partly because clients might
+not stop making an invalid partial request until they have received a complete
+representation. Thus, clients cannot depend on receiving a
+416 (Range Not Satisfiable) response even when it is most appropriate.
+
+Source: [RFC7233 Section 4.4][1]
+
+[1]: <http://tools.ietf.org/html/rfc7233#section-4.4>
+[2]: <http://tools.ietf.org/html/rfc7233#section-3.1>
+[3]: <http://tools.ietf.org/html/rfc7233#section-4.2>

contents/codes/417.md

@@ -2,6 +2,15 @@
 set: 4
 code: 417
 title: Expectation Failed
+references:
+    "Rails HTTP Status Symbol": ":expectation_failed"
 ---
 
-This is the contents of the 417 status code
+The 417 (Expectation Failed) status code indicates that the expectation given in
+the request's Expect header field ([RFC7231 Section 5.1.1][2]) could not be met
+by at least one of the inbound servers.
+
+Source: [RFC7231 Section 6.5.14][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.14>
+[2]: <http://tools.ietf.org/html/rfc7231#section-5.1.1>

contents/codes/418.md

@@ -2,6 +2,13 @@
 set: 4
 code: 418
 title: I'm a teapot
+references:
+    "Rails HTTP Status Symbol": ":i'm_a_teapot"
 ---
 
-This is the contents of the 418 status code
+Any attempt to brew coffee with a teapot should result in the error code
+"418 I'm a teapot". The resulting entity body MAY be short and stout.
+
+Source: [RFC2324 Section 2.3.2][1]
+
+[1]: <https://tools.ietf.org/html/rfc2324#section-2.3.2>

contents/codes/421.md

@@ -2,6 +2,30 @@
 set: 4
 code: 421
 title: Misdirected Request
+references:
+    "Rails HTTP Status Symbol": ":misdirected_request"
 ---
 
-This is the contents of the 421 status code
+The 421 (Misdirected Request) status code indicates that the request was
+directed at a server that is not able to produce a response. This can be sent by
+a server that is not configured to produce responses for the combination of
+scheme and authority that are included in the request URI.
+
+Clients receiving a 421 (Misdirected Request) response from a server MAY retry
+the request -- whether the request method is idempotent or not -- over a
+different connection. This is possible if a connection is reused
+([RFC7540 Section 9.1.1][2]) or if an alternative service is selected
+[ALT-SVC][3].
+
+This status code MUST NOT be generated by proxies.
+
+A 421 response is cacheable by default, i.e., unless otherwise indicated by the
+method definition or explicit cache controls
+(see [Section 4.2.2 of RFC7234][4]).
+
+Source: [RFC7540 Section 9.1.2][1]
+
+[1]: <http://tools.ietf.org/html/rfc7540#section-9.1.2>
+[2]: <http://tools.ietf.org/html/rfc7540#section-9.1.1>
+[3]: <http://tools.ietf.org/html/rfc7540#ref-ALT-SVC>
+[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

contents/codes/422.md

@@ -2,6 +2,18 @@
 set: 4
 code: 422
 title: Unprocessable Entity
+references:
+    "Rails HTTP Status Symbol": ":unprocessable_entity"
 ---
 
-This is the contents of the 422 status code
+The 422 (Unprocessable Entity) status code means the server understands the
+content type of the request entity (hence a [415 (Unsupported Media Type)](/415)
+status code is inappropriate), and the syntax of the request entity is correct
+(thus a [400 (Bad Request)](/400) status code is inappropriate) but was unable
+to process the contained instructions. For example, this error condition may
+occur if an XML request body contains well-formed (i.e., syntactically correct),
+but semantically erroneous, XML instructions.
+
+Source: [RFC4918 Section 11.2][1]
+
+[1]: <http://tools.ietf.org/html/rfc4918#section-11.2>

contents/codes/423.md

@@ -2,6 +2,14 @@
 set: 4
 code: 423
 title: Locked
+references:
+    "Rails HTTP Status Symbol": ":locked"
 ---
 
-This is the contents of the 423 status code
+The 423 (Locked) status code means the source or destination resource of a
+method is locked.  This response SHOULD contain an appropriate precondition or
+postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
+
+Source: [RFC4918 Section 11.3][1]
+
+[1]: <http://tools.ietf.org/html/rfc4918#section-11.3>

contents/codes/424.md

@@ -2,6 +2,16 @@
 set: 4
 code: 424
 title: Failed Dependency
+references:
+    "Rails HTTP Status Symbol": "failed_dependency"
 ---
 
-This is the contents of the 418 status code
+The 424 (Failed Dependency) status code means that the method could not be
+performed on the resource because the requested action depended on another
+action and that action failed.  For example, if a command in a PROPPATCH method
+fails, then, at minimum, the rest of the commands will also fail with
+424 (Failed Dependency).
+
+Source: [RFC4918 Section 11.4][1]
+
+[1]: <http://tools.ietf.org/html/rfc4918#section-11.4>

contents/codes/426.md

@@ -2,6 +2,29 @@
 set: 4
 code: 426
 title: Upgrade Required
+references:
+    "Rails HTTP Status Symbol": ":upgrade_required"
 ---
 
-This is the contents of the 426 status code
+The 426 (Upgrade Required) status code indicates that the server refuses to
+perform the request using the current protocol but might be willing to do so
+after the client upgrades to a different protocol. The server MUST send an
+Upgrade header field in a 426 response to indicate the required protocol(s)
+(Section 6.7 of RFC7230][2]).
+
+Example:
+
+```
+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 protocol.
+```
+
+Source: [RFC7231 Section 6.5.15][1]
+
+[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.15>
+[2]: <http://tools.ietf.org/html/rfc7230#section-6.7>

contents/codes/428.md

@@ -4,4 +4,33 @@ code: 428
 title: Precondition Required
 ---
 
-This is the contents of the 428 status code
+The 428 status code indicates that the origin server requires the request to be
+conditional.
+
+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.
+
+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.
+
+[1]: <http://tools.ietf.org/html/rfc6585#section-3>

contents/codes/429.md

@@ -4,4 +4,40 @@ code: 429
 title: Too Many Requests
 ---
 
-This is the contents of the 429 status code
+The 429 status code indicates that the user has sent too many requests in a
+given amount of time ("rate limiting").
+
+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.
+
+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.
+
+Responses with the 429 status code MUST NOT be stored by a cache.
+
+Source: [RFC6585 Section 4][1]
+
+[1]: <http://tools.ietf.org/html/rfc6585#section-4>

contents/codes/431.md

@@ -4,4 +4,33 @@ code: 431
 title: Request Header Fields Too Large
 ---
 
-This is the contents of the 431 status code
+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.
+
+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.
+
+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.
+
+Source: [RFC6585 Section 5][1]
+
+[1]: <http://tools.ietf.org/html/rfc6585#section-5>

contents/codes/499.md

@@ -6,4 +6,11 @@ code: 499
 title: Client Closed Request
 ---
 
-This is the contents of the 499 status code
+The 499 Client Closed Request status is a non-standard status code introduced by
+[nginx][2] for the case when a client closes the connection while nginx is
+processing the request.
+
+Source: [nginx][1]
+
+[1]: <http://lxr.nginx.org/source/src/http/ngx_http_request.h#0120>
+[2]: <http://nginx.org>