From 2007 to 2014, the IETF HTTP Working Group revised RFC2616, resulting in RFC7230-RFC7235.
This repository contains a copy of the Trac issues list used in that effort, to enable searching and convenient referencing from Github.
It is not an active issues list for these specifications, so please do not file issues here.
New issues for these documents should be directed to httpwg/http-core.
Is a request body allowed on GET? Other requests?
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/19
In Section 3.3.1, RFC2616 says:
<p>"The second format is in common use, but is based on the obsolete RFC 850 [12](../commit/12) date format and lacks a four-digit year."</p>
<p>However, [12](../commit/12) refers to RFC1036, which obsoletes RFC850.</p>
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/47
2616 specifically allows PUT to have side effects;
<blockquote><p>A single resource MAY be identified by many different URIs. For
example, an article might have a URI for identifying "the current
version" which is separate from the URI identifying each particular
version. In this case, a PUT request on a general URI might result
in several other URIs being defined by the origin server.</p>
<p>HTTP/1.1 does not define how a PUT method affects the state of an
origin server.</p></blockquote>
<p>and it also says (in the context of PUT)</p>
<blockquote><p>If a new resource is created, the origin server MUST inform the
user agent via the 201 (Created) response.</p></blockquote>
<p>So, if I PUT something to /foo, and it has the side effect if
creating /foo;2006-04-03, is the response required to be a 201 Created?</p>
<p>I.e., read literally, the above requirement requires a 201 Created
when PUT results in *any* resource being created -- even as a side
effect.</p>
<p>This is IMO unnecessarily constraining, and should be relaxed; e.g.,
changed to something like</p>
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/21
The phrase "unless the message is terminated by closing the connection" in Section 4.4 is unnecessary.
<p>Section 3.6 uses the same phrase; it is a little confusing. In 4.4 you
could almost read it to mean that presence of "Connection: close" would
mean that a T-E header should be ignored, which is presumably not the
intent (and certainly not the practice).</p>
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/28
At present, the behavior in the case where there was a fragment with the original URI, e.g.: http://host1.example.com/resource1#fragment1 where /resource1 redirects to http://host2.example.com/resource2#fragment2 is 'fragment1' discarded? Do you find fragment2 and then find fragment1 within it? We don't have fragment combination rules.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/43
Section 13.5.1 currently ends with:
Other hop-by-hop headers MUST be listed in a Connection header, (section 14.10) to be introduced into HTTP/1.1 (or later).
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/49
It's not clear what the headers in a response to a PUT apply to; for example, does an ETag apply to that response, or the response that would be returned upon a GET?
The same questions apply in other cases where the response serves as a status message.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/22
<li>Section 13.13, page 99: Even though sometimes such resources ought not <del>to</del><ins>be</ins> cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms.</li>
<li>Section 14.18, page 124: The field value is an HTTP-date, as described in section 3.3.1; it MUST be sent in <ins>the </ins>RFC 1123 [8](../commit/8)<del>-</del><ins> </ins>date format.</li>
<li>Section 14.23, page 129: A client MUST include a Host header field in all HTTP/1.1 request messages<del> </del>.</li>
<li>Section 14.32, page 137: Note: because the meaning of "Pragma: no-cache<ins>"</ins> as a response<del> </del><ins>-</ins>header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response<ins>.</ins></li>
<li>Section 15.6, page 155: HTTP/1.1<del>.</del> does not provide a method for a server to direct clients to discard these cached credentials.</li>
<li>Section 2.1, page 15: At least one delimiter (LWS and/or<del><br/></del><ins> </ins>separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.</li>
</ol>
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/50
Is LWS permitted between the field-name and colon?
<p>The grammar of RFC 2616 suggests that it is, because ":" is a
separator character, and thus the rule for implied LWS between
a token and a separator applies.</p>
<p>The wording suggests otherwise, although it is not explicit:</p>
<blockquote><p>Each header field consists of a name followed by a colon
(":") and the field value. Field names are
case-insensitive. The field value MAY be preceded by any
amount of LWS, though a single SP is preferred.</p></blockquote>
<p>The wording explicit states LWS is permitted after the colon,
suggesting that the intention is that it's not permitted before
the colon.</p>
<p>Many authors have taken that interpretion, resulting in most of
the servers I looked at not accepting LWS before the colon.
(They should probably reject the request, but all of them treat
it as an unknown header name including a space in the name token).</p>
<p>Apache now, and Mozilla, accept LWS at that position.</p>
</li>
<li><p>What about LWS before the field-name?</p>
<p>At first sight, this doesn't make sense: LWS at the start of
the line indicates folding. However, all implementations I looked at
accept a line beginning with LWS immediately after the
Request-Line or Status-Line. Some of them treat the initial LWS
as part of the field-name (they don't enforce the limited character
range of tokens), or they skip the LWS.</p>
<p>Apache doesn't look for and ignore LWS prior to the first field-name.
Neither do Squid, thttpd or lighttpd. Mozilla and phttpd do.</p>
<p>Technically, the grammar disallows LWS before the field-name:
Implied LWS is only implied _between_ words and separators.</p>
</li>
</ol>
<p>Both of these inconsistencies between programs, and also that lone CR
is treated as LWS by some and not others, lead to potential security
holes due to non-compliant messages that claim to be HTTP/1.1.
Although it isn't the standard's role to state how a program should
respond to every kind of invalid message, it would be good to clarify
these points because they do have security implications (which was
Apache's stated reason for their change):</p>
<ol>
<li>Whether LWS is actually permitted between the field-name and colon.
(Grammar says it is; wording suggests it isn't. Implementations vary).</li>
<li>Whether LWS is actually permitted before the field-name.
(Grammar says it isn't. Implementations vary).</li>
<li>That lone CR in a line is explicitly not allowed and SHOULD (or
MUST?) be rejected, for the specific reason that implementations
vary as to whether it is treated as LWS, which has security
implications for programs which must match on the field-name.</li>
<li>That invalid field-names (such as containing control characters
or LWS) SHOULD (or MUST?) be rejected.</li>
</ol>
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/30
In the references [section 17], markers for the editors notes got left in; they are meaningless and can be safely ignored. They are:
[jg639] [jg640] [jg641] [jg642] [jg643] [jg644] [jg645] [jg646] [jg647]
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/7
When one cached variant has one Vary header, and then another variant is received with a different Vary header. Lets say the first has
<p><tt>Vary: Accept-Language</tt></p>
<p>and the second</p>
<p><tt>Vary: Accept-Encoding</tt></p>
<p>what is the appropriate behaviour for a cache?</p>
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/38
In [section 13.5.1], which describes End-to-End and Hop-by-Hop headers, the text says:
The following HTTP/1.1 headers are hop-by-hop headers:- Connection - Keep-Alive - Proxy-Authenticate - Proxy-Authorization - TE - Trailer<span class='diff'>s</span> - Transfer-Encoding - Upgrade</pre> <p> But the correct header name is 'Trailer' (no 's'): </p>The following HTTP/1.1 headers are hop-by-hop headers: - Connection - Keep-Alive - Proxy-Authenticate - Proxy-Authorization - TE - Trailer - Transfer-Encoding - UpgradeReported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/9
Default charsets for text media types
2616 Section 3.7.1 states;
<blockquote><p> When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP.</p></blockquote> <p>However, many, if not all, of the text/* media types define their own defaults; text/plain (RFC2046), for example, defaults to ASCII, as does text/xml (RFC3023).</p> <p>How do these format-specific defaults interact with HTTP's default? Is HTTP really overriding them?</p> <p>I'm far from the first to be confused by this text, and I'm sure it's been asked before, but I haven't been able to find a definitive answer. If errata are still being considered, perhaps removing/ modifying this line would be a good start...</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/20
Safe Methods vs Redirection
Section 10.3.2 (301 Moved Permanently) contains the paragraph
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.which fails to consider that there are many other request methods that are safe to automatically redirect, and further that the user agent is able to make that determination based on the request method semantics. In particular, the OPTIONS method is always safe to automatically redirect. Unfortunately, the paragraph was written long before there was OPTIONS, and was never updated to reflect the extensibility of methods. The same problem paragraph is found in sections 10.3.3 and 10.3.8.
The above should be replaced with
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.along with similar changes for sections 10.3.3 and 10.3.8. It would also be helpful for each of the method definition sections to specifically define whether or not the method is safe. OPTIONS, GET, and HEAD are all safe in RFC 2616. HTTP extensions like WebDAV define additional safe methods.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/10
TRACE security considerations
There is an HTTP-related security violation approach found/researched by White Hat Security:
<p> PR: <a href="http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt">http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt</a><br/> Details: <a href="http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf">http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf</a> </p> <p>I bet many of you have seen the related advisories/PR. For those who have not, here is the gist:</p> <p>Modern browsers usually do not allow scripts embedded in HTML to access cookies and authentication information exchanged between HTTP client and server. However, a script can get access to that info by sending a simple HTTP TRACE request to the originating (innocent) server. The user agent will auto-include current authentication info in such request. The server will echo all the authentication information back, for script to read and [mis]use. Apparently, sending an HTTP request is possible via many scripting methods like ActiveX. See the URL above for details.</p> <p>With numerous XSS (cross-site-scripting) vulnerabilities in user agents, this seems like a real and nasty problem. TRACE method support is optional per RFC 2616, but many popular servers support it. White Hat Security advises server administrators to disable support for TRACE.</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/33
Requiring Allow in 405 responses
In RFC 2616, section 10.4.6 405 Method Not Allowed:
<blockquote><p>The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.</p></blockquote> <p>which has the effect of requiring that a server advertise all methods to a resource. In some cases, method implementation is implemented across several (extensible) parts of a server and thus not known. In other cases, it may not be prudent to tell an unauthenticated client all of the methods that might be available to other clients.</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/24
RFC1700 references
RFC1700 ("ASSIGNED NUMBERS") has been obsoleted by RFC3232 ("Assigned Numbers: RFC 1700 is Replaced by an On-line Database").
<p>draft-gettys-http-v11-spec-rev-00 just updates the reference, which I think is a bug.</p> <p>In fact, RFC2616 refers to RCF1700:</p> <ol> <li>for the definition of the default TCP port, </li> <li>for a reference to the character set registry, and</li> <li>for a reference to the media type registry.</li> </ol>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/46
URI includes query
Section 5.1.2 defines a Request-URI as:
Request-URI = "*" | absoluteURI | abs_path | authoritywhere it gets abs_path by reference to RFC 2396; however, the abs_path in RFC 2396 doesn't include a possible query part:
hier_part = ( net_path | abs_path ) [ "?" query ] net_path = "//" authority [ abs_path ] abs_path = "/" path_segmentsThe definition of Request-URI should be:
Request-URI = "*" | absoluteURI | abs_path [ "?" query ] | authorityReported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/11
Vary and non-existant headers
When an origin server selects the response by looking at a request header, and the header does not exist, is it correct for the server to add the name of that header to Vary?
<p>For example, suppose a server's logic is like this pseudo-code:</p>reponse_headers (Vary) = "Accept-Language" IF request_headers (Accept-Language) contains "ja" THEN serve the japanese page ELSE serve the english page ENDIF<p>What is the correct HTTP response when the request doesn't have an Accept-Language header?</p> <p>I would guess that the correct response is to "include Vary: Accept-Language", but that begs the next question:</p> </li> <li> <p>How should a cache treat missing requests headers which are mentioned in Vary, when deciding if a stored entity matches a request?</p> <ul> <li>a. If the stored entity was requested _without_ the header mentioned in Vary, and the new request is also _without_ the header, does the stored entity match? (This would come from scenario 1 above).</li> <li>b. If the stored entity was requested _without_ the header mentioned in Vary, and the new request is _with_ the header, does the stored entity match?</li> <li>c. If the stored entity was requested _with_ the header mentioned in Vary, and the new request is _without_ the header, does the stored entity match?</li> </ul> <p>I would imagine that in case a, the entity matches, and in cases b and c, the entity doesn't match and must be revalidated.</p> <p>But the language of RFC 2616 is a unclear:</p> <blockquote><p>When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request.</p></blockquote> <p>Can the selecting request-headers "match" if they are absent? What about case a?</p> <blockquote><p>The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2.</p></blockquote> <p>Is this supposed to mean that an absent header is equivalent to an empty header, or that an absent header is semantically a distinct value from an empty header, or that an absent header is not considered at all in the decision, or that an absent header cannot be matched even with an absent header in the original request for the cached entity?</p> </li> <li> <p>Does this mean that server code which inspects a header value, and finds the header missing, should look like this instead?</p>IF exists request_headers (Accept-Language) THEN reponse_headers (Vary) = "Accept-Language" ELSE response_headers (Vary) = "*" ENDIF IF request_headers (Accept-Language) contains "ja" THEN serve the japanese page ELSE serve the english page ENDIF<p>The conservative thing to do is to disable cacheing when an examined request-header is absent, but that seems excessively pessimistic.</p> </li> </ul>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/37
Via is a MUST
In the description of the Server header [section 14.38], the Via field is described as a SHOULD:
<blockquote class='error'><p> If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it <span class='diff'>SHOULD</span> include a Via field (as described in section 14.45).</p> </blockquote> <p>It should be a MUST:</p> <blockquote class='correct'><p> If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it <span class='diff'>MUST</span> include a Via field (as described in section 14.45).</p> </blockquote> <p>The requirement is stated correctly in the description of the Via header, <a href='http://www.apps.ietf.org/rfc/rfc2616.html#sec-14.45'> [section 14.45]</a>.</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/5
Cache validators in 206 responses
In Section 10.2.7 the spec implies that it may be ok to use a weak cache validator in a 206 response. The correct language is more restrictive.
If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated 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.
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.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/18
RFC2606 Compliance
Make sure that domain names in examples use names reserved for that purpose (see RFC2606).
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/42
Accept-Encoding BNF
In section 14.3, the definition of Accept-Encoding is given as follows:
Accept-Encoding = "Accept-Encoding" ":" 1#( codings [ ";" "q" "=" qvalue ] )<p>This definition implies that there must be at least one non-null codings. However, just below this definition, one of the examples given has an empty Accept-Encoding field-value:</p> <p> Accept-Encoding: compress, gzip<br/> Accept-Encoding:<br/> Accept-Encoding: *<br/> Accept-Encoding: compress;q=0.5, gzip;q=1.0<br/> Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0</p> <p>Furthermore, the fourth rule for testing whether a content-coding is acceptable mentions the possibility that the field-value may be empty.</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/25
Idempotency
It *appears* that RFC3253 changes the idempotency of PUT; is this allowed? RFC3253 doesn't update or obsolete 2616...
<p>I can see a situation where a 3253-naive client decides to retry a timed-out PUT (after all, it's idempotent) and gets some side effects it didn't bargain for.</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/27
Media Type Registrations
In the description of Internet Media Types in [section 3.7], the wrong RFC is cited for the media type registration process. The text says:
Media-type values are registered with the Internet Assigned Number Authority (IANA [19](../commit/19)). The media type registration process is outlined in RFC 4288 [17](../commit/17). Use of non-registered media types is discouraged.
But should be:
Media-type values are registered with the Internet Assigned Number Authority (IANA [19](../commit/19)). The media type registration process is outlined in RFC 2048 [17](../commit/17). Use of non-registered media types is discouraged.
The cited Reference [section 17] is also incorrect; it is:
[17](../commit/17) Postel, J., "Media Type Registration Procedure", RFC 1590, November 1996.(oddly, the date cited is wrong for that RFC and correct for the right one) It should be:
[17](../commit/17) Freed, N., Klensin, J., and Postel, J., "Mulitpurpose Internet Mail Extensions (MIME) Part Four: Registration Procedure", RFC 2048, November 1996.Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/8
Clarification regarding quoting of charset values
In order to clarify when charset values may be quoted, the following is added to section 3.4:
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.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/14
Unneeded references
RFC1866 and RFC2069 aren't mentioned anywhere in the spec. These references probably are leftovers from revising RFC2068.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/44
OPTIONS *
I'd like to see a clarification about what clients can expect upon OPTIONS *. In particular, can they expect to find out about *any* method name supported on that server? I'm asking because this doesn't seem to be the case for at least two major server bases, being:
- Apache (for instance, additional method names supported by mod_dav aren't listed) and
- generic Java servlet engines (servlet API does not support delegation of requests against "*" to all installed web applications)
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/32
no-store invalidation
Responses to HTTP requests with "Cache-control: no-store" are not cachable. Recently, we came across a cache that does not cache responses to no-store requests but also does not invalidate an older cached entity with the same URL. When future requests stop using no-store, the old cached entity is served.
<p>For example, the following happens in our test case:</p> <ol> <li>Client requests an entity A without using no-store.</li> <li>Cache proxies the transaction and caches the response (entity A).</li> <li>Client requests the same entity A using "Cache-control: no-store".</li> <li>Cache proxies the transaction and does NOT cache the response.</li> <li>Client requests the same entity A again, without using no-store.</li> <li>Cache serves the "old" entity A cached in step #2 above.</li> </ol> <p>Does the cache violate the intent of RFC 2616 in step #6? If yes, should that intent be made explicit (I cannot find any explicit rules prohibiting the above behavior).</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/23
ABNF Update
Update BNF to RFC4234.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/36
Message Length
In the discussion of how to determine the message length [section 4.4], the fourth possibility somehow lost a number of characters. The spec says:
4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self- elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse it; the presence in a request of a Range header with ultiple byte- range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses.It should read:
4.If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type MUST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte- range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/4
Fragments allowed in Location
In the description of the Location header [section 14.30], the ABNF for the Location header is given as:
Location = "Location" ":" absoluteURIThis and the accompanying text are incorrect because the definition of 'absoluteURI', given in RFC 2396 does not include fragment identifiers. The correct syntax for the Location header is:
Location = "Location" ":" absoluteURI [ "#" fragment ]There are circumstances in which a fragment identifier in a Location URL would not be appropriate:
- With a 201 Created response, because in this usage the Location header specifies the URL for the entire created resource.
<li>With a 300 Multiple Choices, since the choice decision is intended to be made on resource characteristics and not fragment characteristics.</li> <li>With 305 Use Proxy.</li> </ul> <p> At present, the behavior in the case where there was a fragment with the original URI, e.g.: http://host1.example.com/resource1#fragment1 where /resource1 redirects to http://host2.example.com/resource2#fragment2 is 'fragment1' discarded? Do you find fragment2 and then find fragment1 within it? We don't have fragment combination rules. </p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/6
Chunk Size Definition
In the description of chunked transfer encoding [section 3.6.1], the syntax for a chunk is given as:
chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLFThe accompanying text defines chunk-size incorrectly as:
The chunk-size field is a string of hex digits indicating the size of the chunk.
This doesn't correctly describe what octets the chunk-size field is counting; it should be:
The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets.
(in other words, the chunk length does not include the count of the octets in the chunk header and trailer).
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/3
Date reference typo
Currently, RFC2616 says about the date format for the "Date" header:
"The field value is an HTTP-date, as described in section 3.3.1; it MUST be sent in RFC 1123 8-date format."
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/48
Normative and Informative references
References are now required to be split into "Normative" and "Informative".
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/35
Out-of-date reference for URIs
RFC2616 refers to RFC2396, RFC1630, RFC1738, and RFC1808, all of which have been obsoleted by RFC3986.
If the reference is changed, it will important to remember to make a decision about the "mark" production in the former (which are unreserved characters) which have been moved to have reserved status in the latter.
By referencing 2396, HTTP allows these characters unescaped in path segments, etc. If 3986 is referenced as-is, they will be effectively disallowed, thereby effectively making a number of existing HTTP URIs invalid.
This includes the exclamation mark ("!"), asterisk ("*"), single-quote ("'"), and open and close parentheses ("(" and ")").
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/34
HTTP Version should be case sensitive
In general, quoted string literals in the spec are defined to be case insensitive, but the HTTP Version token should be case sensitive. In [http://www.apps.ietf.org/rfc/rfc2616.html#sec-3.1 section 3.1] it says:
The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGITIt should add:
The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive. HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGITReported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/1
Revise description of the POST method
The description of POST was broadened over time, and is not clear. It is clarified by the following changes in Section 9.5:
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.
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.
Likewise:
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.
should be:
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/17
Invalidation after Update or Delete
There is some ambiguity in Section13.10 as to how the word 'only' binds here:
In order to prevent denial of service attacks, an invalidation based 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.
The following clarification, along with separating the clause explaining the rationale for the rule, is suggested:
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.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/12
Import query BNF
In section 3.2.2, http_URL is defined as follows:
<blockquote><p>http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]</p></blockquote> <p>However, RFC 2616 does not contain a rule called "query". I assume this is meant to be the same "query" that is defined in RFC 2396, since section 3.2.1 incorporates "URI-reference", "absoluteURI", "relativeURI", "port", "host", "abs_path", "rel_path", and "authority" from that specification (but "query" is missing from this list).</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/26
qdtext BNF
RFC 2616 reads:
<p>A string of text is parsed as a single word if it is quoted using double-quote marks.</p>quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = <any TEXT except <">><p>The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.</p>quoted-pair = "\" CHAR<p>I wrote a regular expression based on the RFC 2616 definition, and that allows "foo\" as a quoted-string. That's not intended, is it?</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/31
Updated reference for language tags
RFC 1766, which is referenced by RFC 2616 section 3.10 as the source for its definition of language tags has a BNF has been updated by RFC3066 (a BCP).
RFC 3066 defines these as:
Language-Tag = Primary-subtag *( "-" Subtag ) Primary-subtag = 1*8ALPHA Subtag = 1*8(ALPHA / DIGIT)HTTP/1.1 RFC 2616 defines these as:
language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHAIn the meantime, RFC3066 has been obsoleted by RFC4646, and the original grammar production defining subtags seems to be gone:
Language-Tag = langtag / privateuse ; private use tag / grandfathered ; grandfathered registrationslangtag = (language
["-" script]
["-" region]
*("-" variant)
*("-" extension)
["-" privateuse])language = (23ALPHA [ extlang ]) ; shortest ISO 639 code
/ 4ALPHA ; reserved for future use
/ 58ALPHA ; registered language subtagextlang = *3("-" 3ALPHA) ; reserved for future use
script = 4ALPHA ; ISO 15924 code
region = 2ALPHA ; ISO 3166 code
/ 3DIGIT ; UN M.49 codevariant = 5*8alphanum ; registered variants
/ (DIGIT 3alphanum)extension = singleton 1*("-" (2*8alphanum))
singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
; Single letters: x/X is reserved for private useprivateuse = ("x"/"X") 1*("-" (1*8alphanum))
grandfathered = 13ALPHA 12("-" (2*8alphanum))
; grandfathered registration
; Note: i is the only singleton
; that starts a grandfathered tagalphanum = (ALPHA / DIGIT) ; letters and numbers
So shouldn't RFC2616 (Section 3.10) stop defining these things, and just normatively refer to RFC4626 for the definition of "Language-Tag"?
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/13
'unsafe' characters
In the rules for comparison of URIs [section 3.2.3], it says:
Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42](../commit/42)) are equivalent to their ""%" HEX HEX" encoding.but RFC 2396 has no definition of a character set called "unsafe".
The paragraph should read:
Characters other than those in the "reserved" set (see RFC 2396 [42](../commit/42)) are equivalent to their ""%" HEX HEX" encoding.This was an historical artifact. An earlier HTTP draft had defined a set of 'unsafe' characters, but they were characters that were not valid in a URI, so making a special case in the comparison rule was not needed.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/2
Remove 'identity' token references
<style type="text/css"> .error {background-color: red} .correct {background-color: green} </style>The "identity" transfer coding was removed, but some references to it were not.
In section 3.6, remove reference to non-existant section
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
It should be:
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
In section 4.4 remove 'other than identity' for Transfer-Encoding case since identity is not a valid value.
2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.
It should be:
2.If a Transfer-Encoding header field (section 14.41) is present, then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.
Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored.
It should be:
Messages MUST NOT include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length MUST be ignored.
In section 19.4.5 remove 'identity' CTE.
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client.
It should be:
HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/16
Security Considerations
What work needs to be done to the Security Considerations section
of RFC2616 to allow publication of a revision? E.g., does HTTP need to specify
a Mandatory To Implement mechanism?Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/41
ETag uniqueness
From experience I think it's also worthwhile to further stress the importance of ETag uniqueness among variants of a URI. Very few implementations get this part correct. In fact most major web servers have issues here...
<p>Some even strongly believe that entities with different Content-Encoding is the same entity, arguing that since most encoding (at least the standardized ones) can be converted to the same identity encoding so they are in fact the same entity and should have the same strong ETag.</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/39
Age calculation
RFC 2616 says:
Because the request that resulted in the returned Age value must have been initiated prior to that Age value's generation, we can correct for delays imposed by the network by recording the time at which the request was initiated. Then, when an Age value is received, it MUST be interpreted relative to the time the request was initiated... So, we compute:
<p>corrected_initial_age = corrected_received_age + (now - request_time)</p> </blockquote> <p>I suspect the formula does not match the true intent of the RFC authors. I believe that corrected_initial_age formula counts server-to-client delays twice. It does that because the corrected_received_age component already accounts for one server-to-client delay. Here is an annotated definition from the RFC:</p>corrected_received_age = max( now - date_value, # trust the clock (includes server-to-client delay!) age_value) # all-HTTP/1.1 paths (no server-to-client delay)<p>I think it is possible to fix the corrected_initial_age formula to match the intent (note this is the *initial* not *received* age):</p>corrected_initial_age = max( now - date_value, # trust the clock (includes delays) age_value + now - request_time) # trust Age, add network delays<p>There is no need for corrected_received_age.</p> <p>Moreover, it looks ALL the formulas computing current_age go away with the above new corrected_initial_age definition as long as "now" is still defined as "the current time" (i.e., the time when current_age is calculated):</p> <pre>current_age = corrected_initial_age</pre> <p>So, we end up with a single formula for all cases and all times:</p> <p>current_age = max(now - date_value, age_value + now - request_time) = = now - min(date_value, request_time - age_value)</p> <p>It even has a clear physical meaning -- the min() part is the conservative estimate of object creation time.</p>Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/29
RFC977 reference
classify RFC977 reference as "informative", and update to RFC3977
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/45
No close on 1xx responses
Section 14.10 says:
HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.
it 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.Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/15
Header registration
A revision of RFC2616 should mention BCP 90 (Registration Procedures for Message Header Fields) and should take over as the authoritative reference for the headers it contains.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/40
Recommend Projects
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
TensorFlow
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
Recommend Topics
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
web
Some thing interesting about web. New door for the world.
server
A server is a program made to process requests and deliver data to clients.
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Visualization
Some thing interesting about visualization, use data art
Game
Some thing interesting about game, make everyone happy.
Recommend Org
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
Facebook
Google