- From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
- Date: Tue, 22 Feb 2011 13:20:59 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Julian, On 17 Feb 2011, at 16:27, Julian Reschke wrote: > So, to resolve issue 137, I did the following changes in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1124>: > > - Made the ABNFs for Status-Code and Reason-Phrase identical to P1; note that their consistency is checked when we build the spec. It could be argued that those ABNF rules should only occur once; feedback appreciated. > Given that the ABNF you are referring to is pretty basic/simple and unlikely to change I don't see an issue with repeating it, it's not likely that the ABNF in P2 is likely to get out of step with the 'authoritative' ABNF in P1. > - Consequently, as the enumeration of status-codes isn't in the ABNF anymore, I moved it into a non-normative "Overview" table. One could argue that it's not needed; but it's probably useful to easier find status code definitions, now that they are spread across multiple documents. > I think it is not harmful and may be useful so the table seems an OK idea to me. > - Also, I removed some redundancy from the prose. > > The new intro to Section 4, with the new subsection 4.1 now reads...: > > -- snip -- > 4. Status Code and Reason Phrase > > The Status-Code element is a 3-digit integer result code of the > attempt to understand and satisfy the request. > > The Reason-Phrase is intended to give a short textual description of > the Status-Code and is intended for the human user. The client is > not required to examine or display the Reason-Phrase. > Maybe use "a human user"? > Status-Code = 3DIGIT > Reason-Phrase = *( WSP / VCHAR / obs-text ) > > HTTP status codes are extensible. HTTP applications are not required > to understand the meaning of all registered status codes, though such > understanding is obviously desirable. However, applications MUST > understand the class of any status code, as indicated by the first > digit, and treat any unrecognized response as being equivalent to the > x00 status code of that class, with the exception that an > unrecognized response MUST NOT be cached. For example, if an > unrecognized status code of 431 is received by the client, it can > safely assume that there was something wrong with its request and > treat the response as if it had received a 400 status code. In such > cases, user agents SHOULD present to the user the representation > enclosed with the response, since that representation is likely to > include human-readable information which will explain the unusual > status. > > 4.1. Overview of Status Codes > > The status codes listed below are defined in Section 8, Section 3 of > [Part4], Section 3 of [Part5], and Section 3 of [Part7]. The reason > phrases listed here are only recommendations -- they can be replaced > by local equivalents without affecting the protocol. > I had to think about this a little to parse it, because I didn't know if "Section 8" was referring to P2 or P4. Maybe it should say "Section 8 of this document, Section 3 of [Part4]..." to make it a little easier to parse (for me at least). Ben > +-------------+------------------------------+----------------------+ > | Status-Code | Reason-Phrase | Defined in... | > +-------------+------------------------------+----------------------+ > | 100 | Continue | Section 8.1.1 | > | 101 | Switching Protocols | Section 8.1.2 | > | 200 | OK | Section 8.2.1 | > | 201 | Created | Section 8.2.2 | > | 202 | Accepted | Section 8.2.3 | > | 203 | Non-Authoritative | Section 8.2.4 | > | | Information | | > | 204 | No Content | Section 8.2.5 | > | 205 | Reset Content | Section 8.2.6 | > | 206 | Partial Content | Section 3.1 of | > | | | [Part5] | > | 300 | Multiple Choices | Section 8.3.1 | > | 301 | Moved Permanently | Section 8.3.2 | > | 302 | Found | Section 8.3.3 | > | 303 | See Other | Section 8.3.4 | > | 304 | Not Modified | Section 3.1 of | > | | | [Part4] | > | 305 | Use Proxy | Section 8.3.6 | > | 307 | Temporary Redirect | Section 8.3.8 | > | 400 | Bad Request | Section 8.4.1 | > | 401 | Unauthorized | Section 3.1 of | > | | | [Part7] | > | 402 | Payment Required | Section 8.4.3 | > | 403 | Forbidden | Section 8.4.4 | > | 404 | Not Found | Section 8.4.5 | > | 405 | Method Not Allowed | Section 8.4.6 | > | 406 | Not Acceptable | Section 8.4.7 | > | 407 | Proxy Authentication | Section 3.2 of | > | | Required | [Part7] | > | 408 | Request Time-out | Section 8.4.9 | > | 409 | Conflict | Section 8.4.10 | > | 410 | Gone | Section 8.4.11 | > | 411 | Length Required | Section 8.4.12 | > | 412 | Precondition Failed | Section 3.2 of | > | | | [Part4] | > | 413 | Request Entity Too Large | Section 8.4.14 | > | 414 | URI Too Long | Section 8.4.15 | > | 415 | Unsupported Media Type | Section 8.4.16 | > | 416 | Requested range not | Section 3.2 of | > | | satisfiable | [Part5] | > | 417 | Expectation Failed | Section 8.4.18 | > | 426 | Upgrade Required | Section 8.4.19 | > | 500 | Internal Server Error | Section 8.5.1 | > | 501 | Not Implemented | Section 8.5.2 | > | 502 | Bad Gateway | Section 8.5.3 | > | 503 | Service Unavailable | Section 8.5.4 | > | 504 | Gateway Time-out | Section 8.5.5 | > | 505 | HTTP Version not supported | Section 8.5.6 | > +-------------+------------------------------+----------------------+ > > Note that this list is not exhaustive -- it does not include > extension status codes defined in other specifications. > -- snip -- > > Best regards, Julian >
Received on Tuesday, 22 February 2011 13:21:29 UTC