From d8a693bf27e8ea7fef51c112488f728bed22b8fe Mon Sep 17 00:00:00 2001 From: Samuel Ryan Date: Sat, 23 Apr 2016 01:12:07 +0100 Subject: [PATCH] Remove markdown line limit (#52) * Removes line length limit from Status Code Markdown This will make the data easier to use when we develop the API, it needs to be consistent, arbitrary new lines (especially in text format) will be a major issue, so some sort of workaround would have to be implemented, easier to simply fix the source files. * Removes line length limit from misc. Markdown files --- LICENSE | 18 ++---------- README.md | 38 ++++++------------------- contents/codes/100.md | 12 ++------ contents/codes/101.md | 13 ++------- contents/codes/102.md | 16 ++--------- contents/codes/200.md | 13 ++------- contents/codes/201.md | 12 ++------ contents/codes/202.md | 8 +----- contents/codes/203.md | 16 +++-------- contents/codes/204.md | 30 +++++--------------- contents/codes/205.md | 19 ++----------- contents/codes/206.md | 65 +++++++------------------------------------ contents/codes/207.md | 32 +++++---------------- contents/codes/208.md | 25 ++++------------- contents/codes/226.md | 24 ++++------------ contents/codes/300.md | 35 ++++------------------- contents/codes/301.md | 19 ++++--------- contents/codes/302.md | 13 ++------- contents/codes/303.md | 29 ++++--------------- contents/codes/304.md | 29 ++++--------------- contents/codes/305.md | 3 +- contents/codes/307.md | 17 +++-------- contents/codes/308.md | 20 ++++--------- contents/codes/400.md | 4 +-- contents/codes/401.md | 15 ++-------- contents/codes/403.md | 13 ++------- contents/codes/404.md | 11 ++------ contents/codes/405.md | 9 ++---- contents/codes/406.md | 12 ++------ contents/codes/407.md | 8 ++---- contents/codes/408.md | 8 ++---- contents/codes/409.md | 14 ++-------- contents/codes/410.md | 19 +++---------- contents/codes/411.md | 6 ++-- contents/codes/412.md | 8 ++---- contents/codes/413.md | 10 ++----- contents/codes/414.md | 13 ++------- contents/codes/415.md | 6 ++-- contents/codes/416.md | 20 ++----------- contents/codes/417.md | 3 +- contents/codes/418.md | 3 +- contents/codes/421.md | 13 ++------- contents/codes/422.md | 9 ++---- contents/codes/423.md | 3 +- contents/codes/424.md | 6 ++-- contents/codes/426.md | 6 ++-- contents/codes/428.md | 9 ++---- contents/codes/429.md | 10 ++----- contents/codes/431.md | 8 ++---- contents/codes/451.md | 19 ++++--------- contents/codes/499.md | 3 +- contents/codes/500.md | 3 +- contents/codes/501.md | 6 ++-- contents/codes/502.md | 3 +- contents/codes/503.md | 11 ++------ contents/codes/504.md | 4 +-- contents/codes/505.md | 9 ++---- contents/codes/506.md | 4 +-- contents/codes/507.md | 7 ++--- contents/codes/508.md | 4 +-- contents/codes/510.md | 14 ++-------- contents/codes/511.md | 33 ++++++---------------- contents/codes/599.md | 6 ++-- contents/error-404.md | 5 +--- contents/error-500.md | 7 ++--- contents/index.md | 8 ++---- 66 files changed, 201 insertions(+), 697 deletions(-) diff --git a/LICENSE b/LICENSE index a9218ff..00fe9ec 100644 --- a/LICENSE +++ b/LICENSE @@ -2,20 +2,8 @@ The MIT License (MIT) Copyright (c) 2015 Samuel Ryan -Permission is hereby granted, free of charge, to any person obtaining a copy -of this software and associated documentation files (the "Software"), to deal -in the Software without restriction, including without limitation the rights -to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -copies of the Software, and to permit persons to whom the Software is -furnished to do so, subject to the following conditions: +Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: -The above copyright notice and this permission notice shall be included in all -copies or substantial portions of the Software. +The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE -SOFTWARE. \ No newline at end of file +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. diff --git a/README.md b/README.md index 0e5f0ae..e17a5cc 100644 --- a/README.md +++ b/README.md @@ -2,47 +2,27 @@ [![Build Status](https://img.shields.io/circleci/project/citricsquid/httpstatuses.svg)](https://circleci.com/gh/citricsquid/httpstatuses) -[httpstatuses.com][5] is an easy to reference database of -HTTP Status Codes with their definitions and helpful code references, each -code is at `httpstatuses.com/code`. All standard codes are included, as are -some non-standard codes that have significant presence in the wild. +[httpstatuses.com][5] is an easy to reference database of HTTP Status Codes with their definitions and helpful code references, each code is at `httpstatuses.com/code`. All standard codes are included, as are some non-standard codes that have significant presence in the wild. ## Contributing -To build you need nodejs, run `npm install` to pull in dependencies and then -`node build`, a preview will be available at [localhost:4887][8]. +To build you need nodejs, run `npm install` to pull in dependencies and then `node build`, a preview will be available at [localhost:4887][8]. -All contributions are welcome! If you have an idea to improve the website please -submit a pull request or [create an issue][1], or provide your thoughts on -[open issues][1]. +All contributions are welcome! If you have an idea to improve the website please submit a pull request or [create an issue][1], or provide your thoughts on [open issues][1]. -Each status code lives in a Markdown file at [contents/codes](contents/codes), -the easiest way to submit changes is via the GitHub editor. When contributing -changes to the status codes please be mindful of the following: +Each status code lives in a Markdown file at [contents/codes](contents/codes), the easiest way to submit changes is via the GitHub editor. When contributing changes to the status codes please be mindful of the following: -* Soft line length of 80 for Markdown * Markdown links should be used as [references instead of inline][2] * If an RFC or external document is referenced, make the reference a link -* Source information on a status code from the most recent standards available - (Status Code standards directory is available on [iana.org][3]) -* The opening paragraph of a status code should describe the meaning, following - paragraphs can describe implementation -* Don't edit the meaning of descriptions, but formatting and structural - changes are a-okay +* Source information on a status code from the most recent standards available (Status Code standards directory is available on [iana.org][3]) +* The opening paragraph of a status code should describe the meaning, following paragraphs can describe implementation +* Don't edit the meaning of descriptions, but formatting and structural changes are a-okay * [Don't double-space after a period][4], and remove any examples of it -* If the description references a section in the current RFC, always add the RFC - identifier. For example "Section 6.6" should become "RFC1234 Section 6.6" +* If the description references a section in the current RFC, always add the RFC identifier. For example "Section 6.6" should become "RFC1234 Section 6.6" ## httpstatus.es -Previously the project was known as [httpstatus.es][6] but -[as per this GitHub issue][7] we migrated to [httpstatuses.com][5] in November -2015 for SEO reasons. The httpstatus.es domain will remain available long term but -use of httpstatuses.com is preferred, everything 301's to -https://httpstatuses.com. The months following the migration have seen a -significant uptake in search engine traffic, if you're running a project on -a ccTLD not considered generic by Google and SEO matters it might be worth -switching to a generic too. +Previously the project was known as [httpstatus.es][6] but [as per this GitHub issue][7] we migrated to [httpstatuses.com][5] in November 2015 for SEO reasons. The httpstatus.es domain will remain available long term but use of httpstatuses.com is preferred, everything 301's to https://httpstatuses.com. The months following the migration have seen a significant uptake in search engine traffic, if you're running a project on a ccTLD not considered generic by Google and SEO matters it might be worth switching to a generic too. [1]: [2]: diff --git a/contents/codes/100.md b/contents/codes/100.md index b1db978..c1e9b79 100644 --- a/contents/codes/100.md +++ b/contents/codes/100.md @@ -8,17 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_CONTINUE" --- -The initial part of a request has been received and has not yet been rejected by -the server. The server intends to send a final response after the request has -been fully received and acted upon. +The initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and acted upon. -When the request contains an Expect header field that includes a 100-continue -expectation, the 100 response indicates that the server wishes to receive the -request payload body[1](#ref-1). The client ought to continue sending -the request and discard the 100 response. +When the request contains an Expect header field that includes a 100-continue expectation, the 100 response indicates that the server wishes to receive the request payload body[1](#ref-1). The client ought to continue sending the request and discard the 100 response. -If the request did not contain an Expect header field containing the -100-continue expectation, the client can simply discard this interim response. +If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response. --- diff --git a/contents/codes/101.md b/contents/codes/101.md index 73236d6..17d94fa 100644 --- a/contents/codes/101.md +++ b/contents/codes/101.md @@ -8,18 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_SWITCHING_PROTOCOLS" --- -The server understands and is willing to comply with the client's request, via -the Upgrade header field[1](#ref-1), for a change in the application -protocol being used on this connection. +The server understands and is willing to comply with the client's request, via the Upgrade header field[1](#ref-1), for a change in the application protocol being used on this connection. -The server MUST generate an Upgrade header field in the response that indicates -which protocol(s) will be switched to immediately after the empty line that -terminates the 101 response. +The server MUST generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the empty line that terminates the 101 response. -It is assumed that the server will only agree to switch protocols when it is -advantageous to do so. For example, switching to a newer version of HTTP might -be advantageous over older versions, and switching to a real-time, synchronous -protocol might be advantageous when delivering resources that use such features. +It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features. --- diff --git a/contents/codes/102.md b/contents/codes/102.md index e5a431d..fa1408c 100644 --- a/contents/codes/102.md +++ b/contents/codes/102.md @@ -7,21 +7,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_PROCESSING" --- -An interim response used to inform the client that the server has accepted the -complete request, but has not yet completed it. +An interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. -This status code SHOULD only be sent when the server has a reasonable -expectation that the request will take significant time to complete. As -guidance, if a method is taking longer than 20 seconds (a reasonable, but -arbitrary value) to process the server SHOULD return a 102 (Processing) -response. The server MUST send a final response after the request has been -completed. +This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed. -Methods can potentially take a long period of time to process, especially -methods that support the Depth header. In such cases the client may time-out the -connection while waiting for a response. To prevent this the server may return a -102 Processing status code to indicate to the client that the server is still -processing the method. +Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 Processing status code to indicate to the client that the server is still processing the method. --- diff --git a/contents/codes/200.md b/contents/codes/200.md index 5b90a4a..0b944c3 100644 --- a/contents/codes/200.md +++ b/contents/codes/200.md @@ -10,9 +10,7 @@ references: The request has succeeded. -The payload sent in a 200 response depends on the request method. For the -methods defined by this specification, the intended meaning of the payload can -be summarized as: +The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as: * `GET` a representation of the target resource * `HEAD` the same representation as `GET`, but without the representation data @@ -21,14 +19,9 @@ be summarized as: * `OPTIONS` a representation of the communications options; * `TRACE` a representation of the request message as received by the end server. -Aside from responses to CONNECT, a 200 response always has a payload, though an -origin server MAY generate a payload body of zero length. If no payload is -desired, an origin server ought to send [204 No Content](/204) instead. For -CONNECT, no payload is allowed because the successful result is a tunnel, which -begins immediately after the 200 response header section. +Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send [204 No Content](/204) instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 200 response header section. -A 200 response is cacheable by default; i.e., unless otherwise indicated by the -method definition or explicit cache controls[1](#ref-1). +A 200 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[1](#ref-1). --- diff --git a/contents/codes/201.md b/contents/codes/201.md index 5cc7c73..81354e1 100644 --- a/contents/codes/201.md +++ b/contents/codes/201.md @@ -8,17 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_CREATED" --- -The request has been fulfilled and has resulted in one or more new resources -being created. +The request has been fulfilled and has resulted in one or more new resources being created. -The primary resource created by the request is identified by either a Location -header field in the response or, if no Location field is received, by the -effective request URI. +The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI. -The 201 response payload typically describes and links to the resource(s) -created. See [Section 7.2 of RFC7231][2] for a discussion of the meaning and -purpose of validator header fields, such as ETag and Last-Modified, in a 201 -response. +The 201 response payload typically describes and links to the resource(s) created. See [Section 7.2 of RFC7231][2] for a discussion of the meaning and purpose of validator header fields, such as ETag and Last-Modified, in a 201 response. --- diff --git a/contents/codes/202.md b/contents/codes/202.md index e2271e9..37303c4 100644 --- a/contents/codes/202.md +++ b/contents/codes/202.md @@ -15,13 +15,7 @@ be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation. -The 202 response is intentionally noncommittal. Its purpose is to allow a server -to accept a request for some other process (perhaps a batch-oriented process -that is only run once per day) without requiring that the user agent's -connection to the server persist until the process is completed. The -representation sent with this response ought to describe the request's current -status and point to (or embed) a status monitor that can provide the user with -an estimate of when the request will be fulfilled. +The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled. --- diff --git a/contents/codes/203.md b/contents/codes/203.md index 7221002..a88fd70 100644 --- a/contents/codes/203.md +++ b/contents/codes/203.md @@ -8,21 +8,13 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_NON_AUTHORITATIVE_INFORMATION" --- -The request was successful but the enclosed payload has been modified from that -of the origin server's [200 OK](/200) response by a transforming -proxy[1](#ref-1). +The request was successful but the enclosed payload has been modified from that of the origin server's [200 OK](/200) response by a transforming proxy[1](#ref-1). -This status code allows the proxy to notify recipients when a transformation has -been applied, since that knowledge might impact later decisions regarding the -content. For example, future cache validation requests for the content might -only be applicable along the same request path (through the same proxies). +This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies). -The 203 response is similar to the Warning code of 214 Transformation -Applied[2](#ref-2), which has the advantage of being applicable to -responses with any status code. +The 203 response is similar to the Warning code of 214 Transformation Applied[2](#ref-2), which has the advantage of being applicable to responses with any status code. -A 203 response is cacheable by default; i.e., unless otherwise indicated by the -method definition or explicit cache controls[3](#ref-3). +A 203 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[3](#ref-3). --- diff --git a/contents/codes/204.md b/contents/codes/204.md index 08ab4af..60d53d8 100644 --- a/contents/codes/204.md +++ b/contents/codes/204.md @@ -8,35 +8,19 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_NO_CONTENT" --- -The server has successfully fulfilled the request and that there is no -additional content to send in the response payload body. +The server has successfully fulfilled the request and that there is no additional content to send in the response payload body. -Metadata in the response header fields refer to the target resource and its -selected representation after the requested action was applied. +Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied. -For example, if a 204 status code is received in response to a PUT request and -the response contains an ETag header field, then the PUT was successful and the -ETag field-value contains the entity-tag for the new representation of that -target resource. +For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource. -The 204 response allows a server to indicate that the action has been -successfully applied to the target resource, while implying that the user agent -does not need to traverse away from its current "document view" (if any). The -server assumes that the user agent will provide some indication of the success -to its user, in accord with its own interface, and apply any new or updated -metadata in the response to its active representation. +The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation. -For example, a 204 status code is commonly used with document editing interfaces -corresponding to a "save" action, such that the document being saved remains -available to the user for editing. It is also frequently used with interfaces -that expect automated data transfers to be prevalent, such as within distributed -version control systems. +For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems. -A 204 response is terminated by the first empty line after the header fields -because it cannot contain a message body. +A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body. -A 204 response is cacheable by default; i.e., unless otherwise indicated by the -method definition or explicit cache controls[1](#ref-1). +A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[1](#ref-1). --- diff --git a/contents/codes/205.md b/contents/codes/205.md index 3d54b63..5db64e6 100644 --- a/contents/codes/205.md +++ b/contents/codes/205.md @@ -8,24 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_RESET_CONTENT" --- -The server has fulfilled the request and desires that the user agent reset the -"document view", which caused the request to be sent, to its original state as -received from the origin server. +The server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server. -This response is intended to support a common data entry use case where the user -receives content that supports data entry (a form, notepad, canvas, etc.), -enters or manipulates data in that space, causes the entered data to be -submitted in a request, and then the data entry mechanism is reset for the next -entry so that the user can easily initiate another input action. +This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action. -Since the 205 status code implies that no additional content will be provided, a -server MUST NOT generate a payload in a 205 response. In other words, a server -MUST do one of the following for a 205 response: a) indicate a zero-length body -for the response by including a Content-Length header field with a value of 0; -b) indicate a zero-length payload for the response by including a -Transfer-Encoding header field with a value of chunked and a message body -consisting of a single chunk of zero-length; or, c) close the connection -immediately after sending the blank line terminating the header section. +Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate a payload in a 205 response. In other words, a server MUST do one of the following for a 205 response: a) indicate a zero-length body for the response by including a Content-Length header field with a value of 0; b) indicate a zero-length payload for the response by including a Transfer-Encoding header field with a value of chunked and a message body consisting of a single chunk of zero-length; or, c) close the connection immediately after sending the blank line terminating the header section. --- diff --git a/contents/codes/206.md b/contents/codes/206.md index d95fadd..40df33f 100644 --- a/contents/codes/206.md +++ b/contents/codes/206.md @@ -8,15 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_PARTIAL_CONTENT" --- -The server is successfully fulfilling a range request for the target resource by -transferring one or more parts of the selected representation that correspond to -the satisfiable ranges found in the request's Range header -field[1](#ref-1). +The server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's Range header field[1](#ref-1). -If a single part is being transferred, the server generating the 206 response -MUST generate a Content-Range header field, describing what range of the -selected representation is enclosed, and a payload consisting of the range. For -example: +If a single part is being transferred, the server generating the 206 response MUST generate a Content-Range header field, describing what range of the selected representation is enclosed, and a payload consisting of the range. For example: ``` HTTP/1.1 206 Partial Content @@ -29,19 +23,9 @@ Content-Type: image/gif ... 26012 bytes of partial image data ... ``` -If multiple parts are being transferred, the server generating the 206 response -MUST generate a "multipart/byteranges" payload[2](#ref-2), and a -Content-Type header field containing the multipart/byteranges media type and its -required boundary parameter. To avoid confusion with single-part responses, a -server MUST NOT generate a Content-Range header field in the HTTP header section -of a multiple part response (this field will be sent in each part instead). +If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload[2](#ref-2), and a Content-Type header field containing the multipart/byteranges media type and its required boundary parameter. To avoid confusion with single-part responses, a server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple part response (this field will be sent in each part instead). -Within the header area of each body part in the multipart payload, the server -MUST generate a Content-Range header field corresponding to the range being -enclosed in that body part. If the selected representation would have had a -Content-Type header field in a [200 OK](/200) response, the server SHOULD -generate that same Content-Type field in the header area of each body part. -For example: +Within the header area of each body part in the multipart payload, the server MUST generate a Content-Range header field corresponding to the range being enclosed in that body part. If the selected representation would have had a Content-Type header field in a [200 OK](/200) response, the server SHOULD generate that same Content-Type field in the header area of each body part. For example: ``` HTTP/1.1 206 Partial Content @@ -63,46 +47,17 @@ Content-Range: bytes 7000-7999/8000 --THIS_STRING_SEPARATES-- ``` -When multiple ranges are requested, a server MAY coalesce any of the ranges that -overlap, or that are separated by a gap that is smaller than the overhead of -sending multiple parts, regardless of the order in which the corresponding -byte-range-spec appeared in the received Range header field. Since the typical -overhead between parts of a multipart/byteranges payload is around 80 bytes, -depending on the selected representation's media type and the chosen boundary -parameter length, it can be less efficient to transfer many small disjoint parts -than it is to transfer the entire selected representation. +When multiple ranges are requested, a server MAY coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding byte-range-spec appeared in the received Range header field. Since the typical overhead between parts of a multipart/byteranges payload is around 80 bytes, depending on the selected representation's media type and the chosen boundary parameter length, it can be less efficient to transfer many small disjoint parts than it is to transfer the entire selected representation. -A server MUST NOT generate a multipart response to a request for a single range, -since a client that does not request multiple parts might not support multipart -responses. However, a server MAY generate a multipart/byteranges payload with -only a single body part if multiple ranges were requested and only one range was -found to be satisfiable or only one range remained after coalescing. A client -that cannot process a multipart/byteranges response MUST NOT generate a request -that asks for multiple ranges. +A server MUST NOT generate a multipart response to a request for a single range, since a client that does not request multiple parts might not support multipart responses. However, a server MAY generate a multipart/byteranges payload with only a single body part if multiple ranges were requested and only one range was found to be satisfiable or only one range remained after coalescing. A client that cannot process a multipart/byteranges response MUST NOT generate a request that asks for multiple ranges. -When a multipart response payload is generated, the server SHOULD send the parts -in the same order that the corresponding byte-range-spec appeared in the -received Range header field, excluding those ranges that were deemed -unsatisfiable or that were coalesced into other ranges. A client that receives a -multipart response MUST inspect the Content-Range header field present in each -body part in order to determine which range is contained in that body part; a -client cannot rely on receiving the same ranges that it requested, nor the same -order that it requested. +When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges. A client that receives a multipart response MUST inspect the Content-Range header field present in each body part in order to determine which range is contained in that body part; a client cannot rely on receiving the same ranges that it requested, nor the same order that it requested. -When a 206 response is generated, the server MUST generate the following header -fields, in addition to those required above, if the field would have been sent -in a [200 OK](/200) response to the same request: Date, Cache-Control, ETag, -Expires, Content-Location, and Vary. +When a 206 response is generated, the server MUST generate the following header fields, in addition to those required above, if the field would have been sent in a [200 OK](/200) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary. -If a 206 is generated in response to a request with an If-Range header field, -the sender SHOULD NOT generate other representation header fields beyond those -required above, because the client is understood to already have a prior -response containing those header fields. Otherwise, the sender MUST generate all -of the representation header fields that would have been sent in a -[200 OK](/200) response to the same request. +If a 206 is generated in response to a request with an If-Range header field, the sender SHOULD NOT generate other representation header fields beyond those required above, because the client is understood to already have a prior response containing those header fields. Otherwise, the sender MUST generate all of the representation header fields that would have been sent in a [200 OK](/200) response to the same request. -A 206 response is cacheable by default; i.e., unless otherwise indicated by -explicit cache controls[3](#ref-3). +A 206 response is cacheable by default; i.e., unless otherwise indicated by explicit cache controls[3](#ref-3). --- diff --git a/contents/codes/207.md b/contents/codes/207.md index db460a0..063df99 100644 --- a/contents/codes/207.md +++ b/contents/codes/207.md @@ -7,37 +7,19 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_MULTI_STATUS" --- -A Multi-Status response conveys information about multiple resources in -situations where multiple status codes might be appropriate. +A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate. -The default Multi-Status response body is a text/xml or application/xml HTTP -entity with a 'multistatus' root element. Further elements contain 200, 300, -400, and 500 series status codes generated during the method invocation. 100 -series status codes SHOULD NOT be recorded in a 'response' XML element. +The default Multi-Status response body is a text/xml or application/xml HTTP entity with a 'multistatus' root element. Further elements contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element. -Although '207' is used as the overall response status code, the recipient needs -to consult the contents of the multistatus response body for further information -about the success or failure of the method execution. The response MAY be used -in success, partial success and also in failure situations. +Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations. -The 'multistatus' root element holds zero or more 'response' elements in any -order, each with information about an individual resource. Each 'response' -element MUST have an 'href' element to identify the resource. +The 'multistatus' root element holds zero or more 'response' elements in any order, each with information about an individual resource. Each 'response' element MUST have an 'href' element to identify the resource. -A Multi-Status response uses one out of two distinct formats for representing -the status: +A Multi-Status response uses one out of two distinct formats for representing the status: -1\. A 'status' element as child of the 'response' element indicates the status -of the message execution for the identified resource as a -whole[1](#ref-1). Some method definitions provide information -about specific status codes clients should be prepared to see in a response. -However, clients MUST be able to handle other status codes, using the generic -rules defined in [RFC2616 Section 10][3]. +1\. A 'status' element as child of the 'response' element indicates the status of the message execution for the identified resource as a whole[1](#ref-1). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in [RFC2616 Section 10][3]. -2\. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' -element instead of 'status', providing information about individual properties -of a resource. This format is specific to PROPFIND and PROPPATCH, and is -described in detail in [RFC4918 Section 9.1][4] and [RFC4918 Section 9.2][5]. +2\. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in [RFC4918 Section 9.1][4] and [RFC4918 Section 9.2][5]. --- diff --git a/contents/codes/208.md b/contents/codes/208.md index cb1b061..40dc940 100644 --- a/contents/codes/208.md +++ b/contents/codes/208.md @@ -6,30 +6,15 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_ALREADY_REPORTED" --- -Used inside a DAV: propstat response element to avoid enumerating the internal -members of multiple bindings to the same collection repeatedly. +Used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly. -For each binding to a collection inside the request's scope, only one will be -reported with a 200 status, while subsequent DAV:response elements for all other -bindings will use the 208 status, and no DAV:response elements for their -descendants are included. +For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included. -Note that the 208 status will only occur for "Depth: infinity" requests, and -that it is of particular importance when the multiple collection bindings cause -a bind loop[1](#ref-1). +Note that the 208 status will only occur for "Depth: infinity" requests, and that it is of particular importance when the multiple collection bindings cause a bind loop[1](#ref-1). -A client can request the DAV:resource-id property in a PROPFIND request to -guarantee that they can accurately reconstruct the binding structure of a -collection with multiple bindings to a single resource. +A client can request the DAV:resource-id property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a collection with multiple bindings to a single resource. -For backward compatibility with clients not aware of the 208 status code -appearing in multistatus response bodies, it SHOULD NOT be used unless the -client has signaled support for this specification using the "DAV" request -header[2](#ref-2). Instead, a [508 Loop Detected](/508) status should -be returned when a binding loop is discovered. This allows the server to return -the 508 as the top-level return status, if it discovers it before it started the -response, or in the middle of a multistatus, if it discovers it in the middle of -streaming out a multistatus response. +For backward compatibility with clients not aware of the 208 status code appearing in multistatus response bodies, it SHOULD NOT be used unless the client has signaled support for this specification using the "DAV" request header[2](#ref-2). Instead, a [508 Loop Detected](/508) status should be returned when a binding loop is discovered. This allows the server to return the 508 as the top-level return status, if it discovers it before it started the response, or in the middle of a multistatus, if it discovers it in the middle of streaming out a multistatus response. --- diff --git a/contents/codes/226.md b/contents/codes/226.md index b457138..91b00f3 100644 --- a/contents/codes/226.md +++ b/contents/codes/226.md @@ -7,29 +7,15 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_IM_USED" --- -The server has fulfilled a GET request for the resource, and the response is a -representation of the result of one or more instance-manipulations applied to -the current instance. +The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. -The actual current instance might not be available except by combining this -response with other previous or future responses, as appropriate for the -specific instance-manipulation(s). If so, the headers of the resulting instance -are the result of combining the headers from the 226 response and the other -instances, following the rules in [section 13.5.3][2] of the -HTTP/1.1 specification. +The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s). If so, the headers of the resulting instance are the result of combining the headers from the 226 response and the other instances, following the rules in [section 13.5.3][2] of the HTTP/1.1 specification. -The request MUST have included an A-IM header field listing at least -one instance-manipulation. The response MUST include an Etag header -field giving the entity tag of the current instance. +The request MUST have included an A-IM header field listing at least one instance-manipulation. The response MUST include an Etag header field giving the entity tag of the current instance. -A response received with a status code of 226 MAY be stored by a -cache and used in reply to a subsequent request, subject to the HTTP -expiration mechanism and any Cache-Control headers, and to the -requirements in [section 10.6][3]. +A response received with a status code of 226 MAY be stored by a cache and used in reply to a subsequent request, subject to the HTTP expiration mechanism and any Cache-Control headers, and to the requirements in [section 10.6][3]. -A response received with a status code of 226 MAY be used by a cache, -in conjunction with a cache entry for the base instance, to create a -cache entry for the current instance. +A response received with a status code of 226 MAY be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the current instance. --- diff --git a/contents/codes/300.md b/contents/codes/300.md index d1c1974..a98d6e3 100644 --- a/contents/codes/300.md +++ b/contents/codes/300.md @@ -8,40 +8,17 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_MULTIPLE_CHOICES" --- -The target resource has more than one representation, each with its own more -specific identifier, and information about the alternatives is being provided -so that the user (or user agent) can select a preferred representation by -redirecting its request to one or more of those identifiers. +The target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. -In other words, the server desires that the user agent engage in reactive -negotiation to select the most appropriate representation(s) for its -needs[1](#ref-1). +In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs[1](#ref-1). -If the server has a preferred choice, the server SHOULD generate a Location -header field containing a preferred choice's URI reference. The user agent MAY -use the Location field value for automatic redirection. +If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection. -For request methods other than HEAD, the server SHOULD generate a payload in the -300 response containing a list of representation metadata and URI reference(s) -from which the user or user agent can choose the one most preferred. The user -agent MAY make a selection from that list automatically if it understands the -provided media type. A specific format for automatic selection is not defined by -this specification because HTTP tries to remain orthogonal to the definition of -its payloads. In practice, the representation is provided in some easily parsed -format believed to be acceptable to the user agent, as determined by shared -design or content negotiation, or in some commonly accepted hypertext format. +For request methods other than HEAD, the server SHOULD generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent MAY make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format. -A 300 response is cacheable by default; i.e., unless otherwise indicated by the -method definition or explicit cache controls[2](#ref-2). +A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[2](#ref-2). -Note: The original proposal for the 300 status code defined the URI header field -as providing a list of alternative representations, such that it would be usable -for 200, 300, and 406 responses and be transferred in responses to the HEAD -method. However, lack of deployment and disagreement over syntax led to both URI -and Alternates (a subsequent proposal) being dropped from this specification. It -is possible to communicate the list using a set of Link header -fields[3](#ref-3), each with a relationship of "alternate", -though deployment is a chicken-and-egg problem. +Note: The original proposal for the 300 status code defined the URI header field as providing a list of alternative representations, such that it would be usable for 200, 300, and 406 responses and be transferred in responses to the HEAD method. However, lack of deployment and disagreement over syntax led to both URI and Alternates (a subsequent proposal) being dropped from this specification. It is possible to communicate the list using a set of Link header fields[3](#ref-3), each with a relationship of "alternate", though deployment is a chicken-and-egg problem. --- diff --git a/contents/codes/301.md b/contents/codes/301.md index c2e6018..86324e8 100644 --- a/contents/codes/301.md +++ b/contents/codes/301.md @@ -8,24 +8,15 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_MOVED_PERMANENTLY" --- -The target resource has been assigned a new permanent URI and any future -references to this resource ought to use one of the enclosed URIs. +The target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. -Clients with link-editing capabilities ought to automatically re-link references -to the effective request URI to one or more of the new references sent by the -server, where possible. +Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible. -The server SHOULD generate a Location header field in the response containing a -preferred URI reference for the new permanent URI. The user agent MAY use the -Location field value for automatic redirection. The server's response payload -usually contains a short hypertext note with a hyperlink to the new URI(s). +The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s). -Note: For historical reasons, a user agent MAY change the request method from -POST to GET for the subsequent request. If this behavior is undesired, the -[307 Temporary Redirect](/307) status code can be used instead. +Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the [307 Temporary Redirect](/307) status code can be used instead. -A 301 response is cacheable by default; i.e., unless otherwise indicated by the -method definition or explicit cache controls[1](#ref-1). +A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[1](#ref-1). --- diff --git a/contents/codes/302.md b/contents/codes/302.md index 3ef42ad..70d64a3 100644 --- a/contents/codes/302.md +++ b/contents/codes/302.md @@ -8,18 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_FOUND" --- -The target resource resides temporarily under a different URI. Since the -redirection might be altered on occasion, the client ought to continue to use -the effective request URI for future requests. +The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests. -The server SHOULD generate a Location header field in the response containing a -URI reference for the different URI. The user agent MAY use the Location field -value for automatic redirection. The server's response payload usually contains -a short hypertext note with a hyperlink to the different URI(s). +The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s). -Note: For historical reasons, a user agent MAY change the request method from -POST to GET for the subsequent request. If this behavior is undesired, the -[307 Temporary Redirect](/307) status code can be used instead. +Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the [307 Temporary Redirect](/307) status code can be used instead. --- diff --git a/contents/codes/303.md b/contents/codes/303.md index ce54f02..98f335e 100644 --- a/contents/codes/303.md +++ b/contents/codes/303.md @@ -8,34 +8,15 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_SEE_OTHER" --- -The server is redirecting the user agent to a different resource, as indicated -by a URI in the Location header field, which is intended to provide an indirect -response to the original request. +The server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request. -A user agent can perform a retrieval request targeting that URI (a GET -or HEAD request if using HTTP), which might also be redirected, and present the -eventual result as an answer to the original request. Note that the new URI in -the Location header field is not considered equivalent to the effective request -URI. +A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI. -This status code is applicable to any HTTP method. It is primarily used to allow -the output of a POST action to redirect the user agent to a selected resource, -since doing so provides the information corresponding to the POST response in a -form that can be separately identified, bookmarked, and cached, independent of -the original request. +This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request. -A 303 response to a GET request indicates that the origin server does not have a -representation of the target resource that can be transferred by the server over -HTTP. However, the Location field value refers to a resource that is descriptive -of the target resource, such that making a retrieval request on that other -resource might result in a representation that is useful to recipients without -implying that it represents the original target resource. Note that answers to -the questions of what can be represented, what representations are adequate, and -what might be a useful description are outside the scope of HTTP. +A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP. -Except for responses to a HEAD request, the representation of a 303 response -ought to contain a short hypertext note with a hyperlink to the same URI -reference provided in the Location header field. +Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the Location header field. --- diff --git a/contents/codes/304.md b/contents/codes/304.md index a3227f5..6eb2d44 100644 --- a/contents/codes/304.md +++ b/contents/codes/304.md @@ -8,34 +8,17 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_NOT_MODIFIED" --- -A conditional GET or HEAD request has been received and would have resulted in a -[200 OK](/200) response if it were not for the fact that the condition evaluated -to false. +A conditional GET or HEAD request has been received and would have resulted in a [200 OK](/200) response if it were not for the fact that the condition evaluated to false. -In other words, there is no need for the server to transfer a representation of -the target resource because the request indicates that the client, which made -the request conditional, already has a valid representation; the server is -therefore redirecting the client to make use of that stored representation as if -it were the payload of a [200 OK](/200) response. +In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the payload of a [200 OK](/200) response. -The server generating a 304 response MUST generate any of the following header -fields that would have been sent in a [200 OK](/200) response to the same -request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. +The server generating a 304 response MUST generate any of the following header fields that would have been sent in a [200 OK](/200) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. -Since the goal of a 304 response is to minimize information transfer when the -recipient already has one or more cached representations, a sender SHOULD NOT -generate representation metadata other than the above listed fields unless said -metadata exists for the purpose of guiding cache updates (e.g., Last-Modified -might be useful if the response does not have an ETag field). +Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field). -Requirements on a cache that receives a 304 response are defined in -[Section 4.3.4 of RFC7234][2]. If the conditional request originated with an -outbound client, such as a user agent with its own cache sending a conditional -GET to a shared proxy, then the proxy SHOULD forward the 304 response to that -client. +Requirements on a cache that receives a 304 response are defined in [Section 4.3.4 of RFC7234][2]. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional GET to a shared proxy, then the proxy SHOULD forward the 304 response to that client. -A 304 response cannot contain a message-body; it is always terminated by the -first empty line after the header fields. +A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields. --- diff --git a/contents/codes/305.md b/contents/codes/305.md index c0de2b9..938168c 100644 --- a/contents/codes/305.md +++ b/contents/codes/305.md @@ -9,8 +9,7 @@ title: Use Proxy # - Due to deprecation we won't show this... but should we? --- -Defined in a previous version of this specification and is now deprecated, due -to security concerns regarding in-band configuration of a proxy. +Defined in a previous version of this specification and is now deprecated, due to security concerns regarding in-band configuration of a proxy. --- diff --git a/contents/codes/307.md b/contents/codes/307.md index b1f012e..7eb676d 100644 --- a/contents/codes/307.md +++ b/contents/codes/307.md @@ -8,22 +8,13 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_TEMPORARY_REDIRECT" --- -The target resource resides temporarily under a different URI and the user agent -MUST NOT change the request method if it performs an automatic redirection to -that URI. +The target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. -Since the redirection can change over time, the client ought to continue using -the original effective request URI for future requests. +Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests. -The server SHOULD generate a Location header field in the response containing a -URI reference for the different URI. The user agent MAY use the Location field -value for automatic redirection. The server's response payload usually contains -a short hypertext note with a hyperlink to the different URI(s). +The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s). -Note: This status code is similar to 302 Found, except that it does not allow -changing the request method from POST to GET. This specification defines no -equivalent counterpart for [301 Moved Permanently](/301) ([RFC7238][2], however, -proposes defining the status code [308 Permanent Redirect](/308) for this purpose). +Note: This status code is similar to 302 Found, except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for [301 Moved Permanently](/301) ([RFC7238][2], however, proposes defining the status code [308 Permanent Redirect](/308) for this purpose). --- diff --git a/contents/codes/308.md b/contents/codes/308.md index 9ce265e..26bb119 100644 --- a/contents/codes/308.md +++ b/contents/codes/308.md @@ -6,25 +6,15 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_PERMANENTLY_REDIRECT" --- -The target resource has been assigned a new permanent URI and any future -references to this resource ought to use one of the enclosed URIs. +The target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. -Clients with link editing capabilities ought to automatically re-link references -to the effective request URI[1](#ref-1) to one or more of the new -references sent by the server, where possible. +Clients with link editing capabilities ought to automatically re-link references to the effective request URI[1](#ref-1) to one or more of the new references sent by the server, where possible. -The server SHOULD generate a Location header field[2](#ref-2) in the -response containing a preferred URI reference for the new permanent URI. The -user agent MAY use the Location field value for automatic redirection. The -server's response payload usually contains a short hypertext note with a -hyperlink to the new URI(s). +The server SHOULD generate a Location header field[2](#ref-2) in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s). -A 308 response is cacheable by default; i.e., unless otherwise indicated by the -method definition or explicit cache controls[3](#ref-3). +A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[3](#ref-3). -Note: This status code is similar to [301 Moved -Permanently](/301), except that it does not allow changing the request method -from POST to GET. +Note: This status code is similar to [301 Moved Permanently](/301), except that it does not allow changing the request method from POST to GET. --- diff --git a/contents/codes/400.md b/contents/codes/400.md index c9cc6d3..955400d 100644 --- a/contents/codes/400.md +++ b/contents/codes/400.md @@ -8,9 +8,7 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_BAD_REQUEST" --- -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). +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). --- diff --git a/contents/codes/401.md b/contents/codes/401.md index 51d6b4f..ca354f5 100644 --- a/contents/codes/401.md +++ b/contents/codes/401.md @@ -8,20 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_UNAUTHORIZED" --- -The request has not been applied because it lacks valid authentication -credentials for the target resource. +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[1](#ref-1) containing at least one challenge applicable to the -target resource. +The server generating a 401 response MUST send a WWW-Authenticate header field[1](#ref-1) 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[2](#ref-2). 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. +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[2](#ref-2). 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. --- diff --git a/contents/codes/403.md b/contents/codes/403.md index 9597dc5..56587eb 100644 --- a/contents/codes/403.md +++ b/contents/codes/403.md @@ -10,18 +10,11 @@ references: 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). +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. +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). +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). --- diff --git a/contents/codes/404.md b/contents/codes/404.md index aad2244..9758a35 100644 --- a/contents/codes/404.md +++ b/contents/codes/404.md @@ -8,16 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_NOT_FOUND" --- -The origin server did not find a current representation for the target resource -or is not willing to disclose that one exists. +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 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[1](#ref-1). +A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[1](#ref-1). --- diff --git a/contents/codes/405.md b/contents/codes/405.md index 07518f3..cd73490 100644 --- a/contents/codes/405.md +++ b/contents/codes/405.md @@ -8,14 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_METHOD_NOT_ALLOWED" --- -The method received in the request-line is known by the origin server but not -supported by the target resource. +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. +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[1](#ref-1). +A 405 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[1](#ref-1). --- diff --git a/contents/codes/406.md b/contents/codes/406.md index 6469751..3201c53 100644 --- a/contents/codes/406.md +++ b/contents/codes/406.md @@ -8,17 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_NOT_ACCEPTABLE" --- -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[1](#ref-1), and the server is -unwilling to supply a default representation. +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[1](#ref-1), 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]. +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]. --- diff --git a/contents/codes/407.md b/contents/codes/407.md index 6e4d30d..a51e5ca 100644 --- a/contents/codes/407.md +++ b/contents/codes/407.md @@ -8,13 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_PROXY_AUTHENTICATION_REQUIRED" --- -Similar to [401 Unauthorized](/401), but it indicates that the client needs to -authenticate itself in order to use a proxy. +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[1](#ref-1) -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[2](#ref-2). +The proxy MUST send a Proxy-Authenticate header field[1](#ref-1) 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[2](#ref-2). --- diff --git a/contents/codes/408.md b/contents/codes/408.md index acb4a4a..136775f 100644 --- a/contents/codes/408.md +++ b/contents/codes/408.md @@ -8,13 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_REQUEST_TIMEOUT" --- -The server did not receive a complete request message within the time that it -was prepared to wait. +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[1](#ref-1) -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. +A server SHOULD send the "close" connection option[1](#ref-1) 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. --- diff --git a/contents/codes/409.md b/contents/codes/409.md index e74c30a..3910125 100644 --- a/contents/codes/409.md +++ b/contents/codes/409.md @@ -8,19 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_CONFLICT" --- -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 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. +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. +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. --- diff --git a/contents/codes/410.md b/contents/codes/410.md index 5e2e5c1..ac0f57a 100644 --- a/contents/codes/410.md +++ b/contents/codes/410.md @@ -8,24 +8,13 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_GONE" --- -The target resource is no longer available at the origin server and that this -condition is likely to be permanent. +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. +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. +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[1](#ref-1). +A 410 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[1](#ref-1). --- diff --git a/contents/codes/411.md b/contents/codes/411.md index 6debce0..ff6895b 100644 --- a/contents/codes/411.md +++ b/contents/codes/411.md @@ -8,11 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_LENGTH_REQUIRED" --- -The server refuses to accept the request without a defined -Content-Length[1](#ref-1). +The server refuses to accept the request without a defined Content-Length[1](#ref-1). -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. +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. --- diff --git a/contents/codes/412.md b/contents/codes/412.md index c5c4a15..de01057 100644 --- a/contents/codes/412.md +++ b/contents/codes/412.md @@ -8,13 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_PRECONDITION_FAILED" --- -One or more conditions given in the request header fields evaluated to false -when tested on the server. +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. +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. --- diff --git a/contents/codes/413.md b/contents/codes/413.md index e2f0208..612296c 100644 --- a/contents/codes/413.md +++ b/contents/codes/413.md @@ -8,15 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_REQUEST_ENTITY_TOO_LARGE" --- -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 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. +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. +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. --- diff --git a/contents/codes/414.md b/contents/codes/414.md index 5302b76..18c744a 100644 --- a/contents/codes/414.md +++ b/contents/codes/414.md @@ -8,18 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_REQUEST_URI_TOO_LONG" --- -The server is refusing to service the request because the -request-target[1](#ref-1) is longer than the server is willing to -interpret. +The server is refusing to service the request because the request-target[1](#ref-1) 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. +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 [2](#ref-2). +A 414 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls [2](#ref-2). --- diff --git a/contents/codes/415.md b/contents/codes/415.md index b282919..3a2c1dc 100644 --- a/contents/codes/415.md +++ b/contents/codes/415.md @@ -8,11 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_UNSUPPORTED_MEDIA_TYPE" --- -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 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. +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. --- diff --git a/contents/codes/416.md b/contents/codes/416.md index e90537f..ca77b6a 100644 --- a/contents/codes/416.md +++ b/contents/codes/416.md @@ -8,17 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_REQUESTED_RANGE_NOT_SATISFIABLE" --- -None of the ranges in the request's Range header field[1](#ref-1) -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. +None of the ranges in the request's Range header field[1](#ref-1) 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[2](#ref-2). +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[2](#ref-2). For example: @@ -28,13 +20,7 @@ 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. +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. --- diff --git a/contents/codes/417.md b/contents/codes/417.md index dcce627..34025cb 100644 --- a/contents/codes/417.md +++ b/contents/codes/417.md @@ -8,8 +8,7 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_EXPECTATION_FAILED" --- -The expectation given in the request's Expect header field[1](#ref-1) -could not be met by at least one of the inbound servers. +The expectation given in the request's Expect header field[1](#ref-1) could not be met by at least one of the inbound servers. --- diff --git a/contents/codes/418.md b/contents/codes/418.md index f029b92..e4e4037 100644 --- a/contents/codes/418.md +++ b/contents/codes/418.md @@ -7,8 +7,7 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_I_AM_A_TEAPOT" --- -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. +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. --- diff --git a/contents/codes/421.md b/contents/codes/421.md index 1a81878..cc4ce91 100644 --- a/contents/codes/421.md +++ b/contents/codes/421.md @@ -6,20 +6,13 @@ references: "Rails HTTP Status Symbol": ":misdirected_request" --- -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. +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[1](#ref-1)or if an alternative service is selected -[ALT-SVC][3]. +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[1](#ref-1)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[2](#ref-2). +A 421 response is cacheable by default, i.e., unless otherwise indicated by the method definition or explicit cache controls[2](#ref-2). --- diff --git a/contents/codes/422.md b/contents/codes/422.md index 693f69d..212f850 100644 --- a/contents/codes/422.md +++ b/contents/codes/422.md @@ -7,14 +7,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_UNPROCESSABLE_ENTITY" --- -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. +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. +For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions. --- diff --git a/contents/codes/423.md b/contents/codes/423.md index 0ac7e0b..0a4372d 100644 --- a/contents/codes/423.md +++ b/contents/codes/423.md @@ -9,8 +9,7 @@ references: 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'. +This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'. --- diff --git a/contents/codes/424.md b/contents/codes/424.md index d18c290..7807795 100644 --- a/contents/codes/424.md +++ b/contents/codes/424.md @@ -7,11 +7,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_FAILED_DEPENDENCY" --- -The method could not be performed on the resource because the requested action -depended on another action and that action failed. +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. +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. --- diff --git a/contents/codes/426.md b/contents/codes/426.md index 9933888..19c39bd 100644 --- a/contents/codes/426.md +++ b/contents/codes/426.md @@ -7,11 +7,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_UPGRADE_REQUIRED" --- -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 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)[1](#ref-1) +The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s)[1](#ref-1) Example: diff --git a/contents/codes/428.md b/contents/codes/428.md index b0188fa..27e0f19 100644 --- a/contents/codes/428.md +++ b/contents/codes/428.md @@ -8,14 +8,9 @@ references: 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. +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: +Responses using this status code SHOULD explain how to resubmit the request successfully. For example: ``` HTTP/1.1 428 Precondition Required diff --git a/contents/codes/429.md b/contents/codes/429.md index f254893..4972543 100644 --- a/contents/codes/429.md +++ b/contents/codes/429.md @@ -8,9 +8,7 @@ references: 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. +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: @@ -31,11 +29,7 @@ Retry-After: 3600 ``` -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. +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. diff --git a/contents/codes/431.md b/contents/codes/431.md index 231521e..8ef19d7 100644 --- a/contents/codes/431.md +++ b/contents/codes/431.md @@ -6,13 +6,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE" --- -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. +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. +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: diff --git a/contents/codes/451.md b/contents/codes/451.md index d58ca7a..4e38589 100644 --- a/contents/codes/451.md +++ b/contents/codes/451.md @@ -9,13 +9,9 @@ references: The server is denying access to the resource as a consequence of a legal demand. -The server in question might not be an origin server. This type of legal demand -typically most directly affects the operations of ISPs and search engines. +The server in question might not be an origin server. This type of legal demand typically most directly affects the operations of ISPs and search engines. -Responses using this status code SHOULD include an explanation, in the response -body, of the details of the legal demand: the party making it, the applicable -legislation or regulation, and what classes of person and resource it applies -to. For example: +Responses using this status code SHOULD include an explanation, in the response body, of the details of the legal demand: the party making it, the applicable legislation or regulation, and what classes of person and resource it applies to. For example: ``` HTTP/1.1 451 Unavailable For Legal Reasons @@ -36,16 +32,11 @@ Content-Type: text/html ``` -The use of the 451 status code implies neither the existence nor non- -existence of the resource named in the request. That is to say, it is possible -that if the legal demands were removed, a request for the resource still might -not succeed. +The use of the 451 status code implies neither the existence nor non- existence of the resource named in the request. That is to say, it is possible that if the legal demands were removed, a request for the resource still might not succeed. -Note that in many cases clients can still access the denied resource by using -technical countermeasures such as a VPN or the Tor network. +Note that in many cases clients can still access the denied resource by using technical countermeasures such as a VPN or the Tor network. -A 451 response is cacheable by default; i.e., unless otherwise indicated by the -method definition or explicit cache controls; see [RFC7234][2]. +A 451 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls; see [RFC7234][2]. --- diff --git a/contents/codes/499.md b/contents/codes/499.md index 82e522c..fbc30b3 100644 --- a/contents/codes/499.md +++ b/contents/codes/499.md @@ -6,8 +6,7 @@ code: 499 title: Client Closed Request --- -A non-standard status code introduced by [nginx][2] for the case when a client -closes the connection while nginx is processing the request. +A non-standard status code introduced by [nginx][2] for the case when a client closes the connection while nginx is processing the request. --- diff --git a/contents/codes/500.md b/contents/codes/500.md index b122443..12c969f 100644 --- a/contents/codes/500.md +++ b/contents/codes/500.md @@ -8,8 +8,7 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_INTERNAL_SERVER_ERROR" --- -The server encountered an unexpected condition that prevented it from fulfilling -the request. +The server encountered an unexpected condition that prevented it from fulfilling the request. --- diff --git a/contents/codes/501.md b/contents/codes/501.md index 88b9530..230a62c 100644 --- a/contents/codes/501.md +++ b/contents/codes/501.md @@ -10,11 +10,9 @@ references: The server does not support the functionality required to fulfill the request. -This is the appropriate response when the server does not recognize the request -method and is not capable of supporting it for any resource. +This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. -A 501 response is cacheable by default; i.e., unless otherwise indicated by the -method definition or explicit cache controls[1](#ref-1). +A 501 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls[1](#ref-1). --- diff --git a/contents/codes/502.md b/contents/codes/502.md index b7379c3..941334c 100644 --- a/contents/codes/502.md +++ b/contents/codes/502.md @@ -8,8 +8,7 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_BAD_GATEWAY" --- -The server, while acting as a gateway or proxy, received an invalid response -from an inbound server it accessed while attempting to fulfill the request. +The server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request. --- diff --git a/contents/codes/503.md b/contents/codes/503.md index e553685..a44bf8f 100644 --- a/contents/codes/503.md +++ b/contents/codes/503.md @@ -8,16 +8,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_SERVICE_UNAVAILABLE" --- -The server is currently unable to handle the request due to a temporary overload -or scheduled maintenance, which will likely be alleviated after some delay. +The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. -The server MAY send a Retry-After header field[1](#ref-1) to suggest -an appropriate amount of time for the client to wait before retrying the -request. +The server MAY send a Retry-After header field[1](#ref-1) to suggest an appropriate amount of time for the client to wait before retrying the request. -Note: The existence of the 503 status code does not imply that a server has to -use it when becoming overloaded. Some servers might simply refuse the -connection. +Note: The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection. --- diff --git a/contents/codes/504.md b/contents/codes/504.md index 28c6ba1..f7663ec 100644 --- a/contents/codes/504.md +++ b/contents/codes/504.md @@ -8,9 +8,7 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_GATEWAY_TIMEOUT" --- -The server, while acting as a gateway or proxy, did not receive a timely -response from an upstream server it needed to access in order to complete the -request. +The server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request. --- diff --git a/contents/codes/505.md b/contents/codes/505.md index 3bc1e81..8438e0e 100644 --- a/contents/codes/505.md +++ b/contents/codes/505.md @@ -8,14 +8,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_VERSION_NOT_SUPPORTED" --- -The server does not support, or refuses to support, the major version of HTTP -that was used in the request message. +The server does not support, or refuses to support, the major version of HTTP that was used in the request message. -The server is indicating that it is unable or unwilling to complete the request -using the same major version as the client, as described in -[Section 2.6 of RFC7230][2], other than with this error message. The server -SHOULD generate a representation for the 505 response that describes why that -version is not supported and what other protocols are supported by that server. +The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in [Section 2.6 of RFC7230][2], other than with this error message. The server SHOULD generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server. --- diff --git a/contents/codes/506.md b/contents/codes/506.md index 5a6b3e1..f1040ee 100644 --- a/contents/codes/506.md +++ b/contents/codes/506.md @@ -6,9 +6,7 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_VARIANT_ALSO_NEGOTIATES_EXPERIMENTAL" --- -The server has an internal configuration error: the chosen variant resource is -configured to engage in transparent content negotiation itself, and is therefore -not a proper end point in the negotiation process. +The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process. --- diff --git a/contents/codes/507.md b/contents/codes/507.md index d1cdb4a..659ee17 100644 --- a/contents/codes/507.md +++ b/contents/codes/507.md @@ -7,12 +7,9 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_INSUFFICIENT_STORAGE" --- -The method could not be performed on the resource because the server is unable -to store the representation needed to successfully complete the request. +The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. -This condition is considered to be temporary. If the request that received this -status code was the result of a user action, the request MUST NOT be repeated -until it is requested by a separate user action. +This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action. --- diff --git a/contents/codes/508.md b/contents/codes/508.md index 5ddb30a..c1a4c8d 100644 --- a/contents/codes/508.md +++ b/contents/codes/508.md @@ -6,9 +6,7 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_LOOP_DETECTED" --- -The server terminated an operation because it encountered an infinite loop while -processing a request with "Depth: infinity". This status indicates that the -entire operation failed. +The server terminated an operation because it encountered an infinite loop while processing a request with "Depth: infinity". This status indicates that the entire operation failed. --- diff --git a/contents/codes/510.md b/contents/codes/510.md index b1ef058..ca4a033 100644 --- a/contents/codes/510.md +++ b/contents/codes/510.md @@ -7,19 +7,11 @@ references: "Symfony HTTP Status Constant": "Response::HTTP_NOT_EXTENDED" --- -The policy for accessing the resource has not been met in the request. The -server should send back all the information necessary for the client to issue an -extended request. +The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request. -It is outside the scope of this specification to specify how -the extensions inform the client. +It is outside the scope of this specification to specify how the extensions inform the client. -If the 510 response contains information about extensions that were not present -in the initial request then the client MAY repeat the request if it has reason -to believe it can fulfill the extension policy by modifying the request -according to the information provided in the 510 response. Otherwise the client -MAY present any entity included in the 510 response to the user, since that -entity may include relevant diagnostic information. +If the 510 response contains information about extensions that were not present in the initial request then the client MAY repeat the request if it has reason to believe it can fulfill the extension policy by modifying the request according to the information provided in the 510 response. Otherwise the client MAY present any entity included in the 510 response to the user, since that entity may include relevant diagnostic information. --- diff --git a/contents/codes/511.md b/contents/codes/511.md index eab2077..20b6f62 100644 --- a/contents/codes/511.md +++ b/contents/codes/511.md @@ -8,36 +8,21 @@ references: The client needs to authenticate to gain network access. -The response representation SHOULD contain a link to a resource that allows the -user to submit credentials (e.g., with an HTML form). +The response representation SHOULD contain a link to a resource that allows the user to submit credentials (e.g., with an HTML form). -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. +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. -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. +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. Responses with the 511 status code MUST NOT be stored by a cache. -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. +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. -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. +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. -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. +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. -For example, a user agent might connect to a network and make the following HTTP -request on TCP port 80: +For example, a user agent might connect to a network and make the following HTTP request on TCP port 80: ``` GET /index.htm HTTP/1.1 @@ -63,9 +48,7 @@ Content-Type: text/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. +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. --- diff --git a/contents/codes/599.md b/contents/codes/599.md index 7dd3413..4506c2b 100644 --- a/contents/codes/599.md +++ b/contents/codes/599.md @@ -6,12 +6,10 @@ code: 599 title: Network Connect Timeout Error --- -This status code is not specified in any RFCs, but is used by some HTTP proxies -to signal a network connect timeout behind the proxy to a client in front of the -proxy. +This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy. --- * Source: [unknown?][1] -[1]: \ No newline at end of file +[1]: diff --git a/contents/error-404.md b/contents/error-404.md index d66c643..f72b1d9 100644 --- a/contents/error-404.md +++ b/contents/error-404.md @@ -5,10 +5,7 @@ layout: page.jade # 404 Page Not Found -This isn't a page to explain a status code, it's an actual 404. -The page you have requested can't be found. If you didn't expect to see -this error please -[create an issue via GitHub](https://github.com/citricsquid/httpstatuses/issues). +This isn't a page to explain a status code, it's an actual 404. The page you have requested can't be found. If you didn't expect to see this error please [create an issue via GitHub](https://github.com/citricsquid/httpstatuses/issues). If you want to learn more about what a 404 is, visit [/404](/404)! diff --git a/contents/error-500.md b/contents/error-500.md index 30efe38..96294d2 100644 --- a/contents/error-500.md +++ b/contents/error-500.md @@ -5,11 +5,8 @@ layout: page.jade # Internal Server Error -This isn't a page to explain a status code, it's an actual 500, an Internal Server -Error. The page you have requested couldn't be delivered for an unknown reason. -If you didn't expect to see this error please -[create an issue via GitHub](https://github.com/citricsquid/httpstatuses/issues). +This isn't a page to explain a status code, it's an actual 500, an Internal Server Error. The page you have requested couldn't be delivered for an unknown reason. If you didn't expect to see this error please [create an issue via GitHub](https://github.com/citricsquid/httpstatuses/issues). If you want to learn more about what a 500 is, visit [/500](/500)! -[← Return to httpstatuses.com](/) \ No newline at end of file +[← Return to httpstatuses.com](/) diff --git a/contents/index.md b/contents/index.md index 691e2fb..e3e32d1 100644 --- a/contents/index.md +++ b/contents/index.md @@ -5,10 +5,6 @@ layout: index.jade # HTTP Status Codes -httpstatuses.com is an easy to reference database of HTTP Status Codes with their -definitions and helpful code references all in one place. Visit an individual -status code via `httpstatuses.com/code` or browse the list below. +httpstatuses.com is an easy to reference database of HTTP Status Codes with their definitions and helpful code references all in one place. Visit an individual status code via `httpstatuses.com/code` or browse the list below. -Hosting sponsored by [Runscope](https://www.runscope.com/t/httpstatuses), -source code available on -[GitHub](https://github.com/citricsquid/httpstatuses). \ No newline at end of file +Hosting sponsored by [Runscope](https://www.runscope.com/t/httpstatuses), source code available on [GitHub](https://github.com/citricsquid/httpstatuses).