- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 17 Feb 2011 17:27:28 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
Hi,
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/137> is one of these
TODOs that are left-overs from splitting RFC 2616 into multiple pieces.
RFC 2616 did use ABNF not only to define parsing, but also to define
legal values, such as method names, status codes, and header field names.
This doesn't make a lot of sense, as parsing a message into components
and acting upon specific values are separate activities. So the goal is
that the ABNF in Part 1 fully defines how to parse messages, and doesn't
have references to other parts.
This left us with strange constructs like the Status-Code/Reason-Phrase
ABNF appearing in both parts; in P1 just saying "3DIGIT", but in P2
enumerating all of "our" status codes, plus an ABNF rule for extension
codes.
(Similar problems exist for header field names and method names, btw.)
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.
- 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.
- 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.
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.
+-------------+------------------------------+----------------------+
| 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 Thursday, 17 February 2011 16:28:13 UTC