-
-
-
+[[ Text in double brackets is from the unofficial errata at ]]
+[[ http://skrb.org/ietf/http_errata.html ]]
Network Working Group R. Fielding
The version of an HTTP message is indicated by an HTTP-Version field
- in the first line of the message.
+ in the first line of the message. [[HTTP-Version is case-sensitive.]]
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
+ [[ Ignore reference to "unsafe" set. ]]
For example, the following three URIs are equivalent:
charset = token
+[[ HTTP uses charset in two contexts: within an Accept-Charset request ]]
+[[ header (in which the charset value is an unquoted token) and as the ]]
+[[ value of a parameter in a Content-type header (within a request or ]]
+[[ response), in which case the parameter value of the charset ]]
+[[ parameter may be quoted. ]]
+
Although HTTP allows an arbitrary token to be used as a charset
value, any token that has a predefined value within the IANA
Character Set registry [19] MUST represent the character set defined
3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
(section 3.5).
+ [[ Remove reference to "identity" token ]]
+
New transfer-coding value tokens SHOULD be registered in the same way
as new content-coding value tokens (section 3.5).
the chunk. The chunked encoding is ended by any chunk whose size is
zero, followed by the trailer, which is terminated by an empty line.
+ [[ "the size of the chunk" means "the size of the chunk-data in ]]
+ [[ octets" ]]
+
The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be
used to indicate which header fields are included in a trailer (see
outlined in RFC 1590 [17]. Use of non-registered media types is
discouraged.
+ [[ "RFC 1590" should be "RFC 2048" ]]
+
3.7.1 Canonicalization and Text Defaults
Internet media types are registered with a canonical form. An
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
+ [[ Updated by RFC 3066: subtags may now contain digits ]]
+
White space is not allowed within the tag and all tags are case-
insensitive. The name space of language tags is administered by the
IANA. Example tags include:
defined by use of the "chunked" transfer-coding (section 3.6),
unless the message is terminated by closing the connection.
+ [[ Remove 'and has any value other than "identity"' ]]
+
3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
non-identity transfer-coding. If the message does include a non-
identity transfer-coding, the Content-Length MUST be ignored.
+ [[ Remove "non-identity" both times ]]
+
When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
identifies the resource upon which to apply the request.
Request-URI = "*" | absoluteURI | abs_path | authority
+ [[ Request-URI = "*" | absoluteURI | abs_path [ "?" query ] | authority ]]
The four options for Request-URI are dependent on the nature of the
request. The asterisk "*" means that the request does not apply to a
identified by the Request-URI in the Request-Line. POST is designed
to allow a uniform method to cover the following functions:
+[[ Should be: ]]
+[[ The POST method is used to request that the origin server accept the ]]
+[[ entity enclosed in the request as data to be processed by the resource ]]
+[[ identified by the Request-URI in the Request-Line. POST is designed ]]
+[[ to allow a uniform method to cover the following functions: ]]
+
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
newsgroup to which it is posted, or a record is subordinate to a
database.
+ [[ Remove second sentence ("The posted entity is subordinate") above ]]
+
The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
MUST include all of the entity-headers that would have been returned
with a 200 (OK) response to the same request.
+[[ Should be: ]]
+[[ If the 206 response is the result of an If-Range request, the ]]
+[[ response SHOULD NOT include other entity-headers. Otherwise, the ]]
+[[ response MUST include all of the entity-headers that would have ]]
+[[ been returned with a 200 (OK) response to the same request. ]]
+
A cache MUST NOT combine a 206 response with other previously cached
content if the ETag or Last-Modified headers do not match exactly,
see 13.5.4.
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
+[[ Should be: ]]
+[[ If the 301 status code is received in response to a request method ]]
+[[ that is known to be "safe", as defined in section 9.1.1, then the ]]
+[[ request MAY be automatically redirected by the user agent without ]]
+[[ confirmation. Otherwise, the user agent MUST NOT automatically ]]
+[[ redirect the request unless it is confirmed by the user, since the ]]
+[[ new URI might change the conditions under which the request was ]]
+[[ issued. ]]
+
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
+ [[ See errata to 10.3.3 ]]
+
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
+ [[ See errata to 10.3.3 ]]
+
10.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the
- Proxy-Authenticate
- Proxy-Authorization
- TE
- - Trailers
+ - Trailers [[should be "Trailer"]]
- Transfer-Encoding
- Upgrade
on the URI in a Location or Content-Location header MUST only be
performed if the host part is the same as in the Request-URI.
+[[ Should be: ]]
+[[ An invalidation based on the URI in a Location or Content-Location ]]
+[[ header MUST NOT be performed if the host part of that URI differs ]]
+[[ from the host part in the Request-URI. This helps prevent denial of ]]
+[[ service attacks. ]]
+
A cache that passes through requests for methods it does not
understand SHOULD invalidate any entities referred to by the
Request-URI.
1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
+ [[ http://lists.w3.org/Archives/Public/ietf-http-wg/2005AprJun/0029.html ]]
+ [[ points out that the "1#" must be "#" to make the examples below and ]]
+ [[ the text of rule 4 correct. ]]
+
Examples of its use are:
Accept-Encoding: compress, gzip
HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message.
+[[ Should say: ]]
+[[ An HTTP/1.1 client that does not support persistent connections ]]
+[[ MUST include the "close" connection option in every request message. ]]
+[[ ]]
+[[ An HTTP/1.1 server that does not support persistent connections ]]
+[[ MUST include the "close" connection option in every response ]]
+[[ message that does not have a 1xx (informational) status code. ]]
+
A system receiving an HTTP/1.0 (or lower-version) message that
includes a Connection header MUST, for each connection-token in this
field, remove and ignore any header field(s) from the message with
field value consists of a single absolute URI.
Location = "Location" ":" absoluteURI
+ [[ [ "#" fragment ] ]]
An example is:
If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (as described in section 14.45).
+ [[ Actually, it MUST ]]
Note: Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks
[17] Postel, J., "Media Type Registration Procedure", RFC 1590,
November 1996.
+[[ Should be: ]]
+[[ [17] Freed, N., Klensin, J., and Postel, J., "Multipurpose Internet ]]
+[[ Mail Extensions (MIME) Part Four: "Registration Procedure", ]]
+[[ RFC 2048, November 1996. ]]
+
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
959, October 1985.
remove any non-identity CTE ("quoted-printable" or "base64") encoding
prior to delivering the response message to an HTTP client.
+ [[ "MUST remove any CTE encoding prior to delivering the response ]]
+ [[ message to an HTTP client." ]]
+
Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format
and encoding for safe transport on that protocol, where "safe
projects / platform / upstream / libsoup.git / commitdiff