The identifier is a name for the issue (and is unique within this document).
The type of issue is one of:
The status of the issue is one of:
The reference is an indication of where the issue was first raised.
The description is a succinct overview of the issue.
The resolution describes the specification change that resolves the issue.
| Identifier | Type / Status | Reference and Description | Proposed Resolution / Latest Change |
|---|---|---|---|
| 14.11-content-encoding_response_vs_message |
change open |
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0269.html> a-travis@microsoft.com, 2006-12-14: The third paragraph of section 14.11 (page 118) reads as follows: "If the content-coding of an entity is not "identity", then the response MUST include a Content-Encoding entity-header (section 14.11) that lists the non-identity content-coding(s) used." Aside from being self-referential, the phrasing can be interpreted in at least two ways, neither of which is probably the intended meaning: * If the content-coding of an entity [in the request] is not "identity", then the response MUST include a Content-Encoding entity header [...]. * If the content-coding of an entity [at the URI requested by the client] is not "identity", then the response MUST include a Content-Encoding entity header [...]. Because the requirement specifically applies to "the response", both of these interpretations place a burden only on the server. The client is not required to declare any Content-Encoding values on its request message. However, the paragraph afterward (as well as the BNF for Request; Section 5, P35) implies that clients are allowed to send content-encoded messages to the server (because the server SHOULD respond with a 415 status). Thus, unless it is truly the case that clients are NOT required to explicitly identify content-encodings, I would suggest the following modification: "If the content-encoding of an entity is not "identity", then the -- Travis (See also <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0269.html>) |
latest change in revision latest |
| abnf |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i36> julian.reschke@greenbytes.de, 2006-12-03: Update BNF to RFC4234 (plan to be added). julian.reschke@greenbytes.de, 2007-07-24: See <http://www.w3.org/mid/45FBAB8C.6010809@gmx.de> for a to-do list. julian.reschke@greenbytes.de, 2007-11-13: See <http://www.w3.org/mid/4739C417.2040203@gmx.de> for a summary of issues with the current ABNF. |
latest change in revision latest |
| abnf-avoid-prose |
change open |
julian.reschke@greenbytes.de, 2007-11-23: Avoid prose when an exact rule can be specified. | latest change in revision latest |
| edit |
edit open |
julian.reschke@greenbytes.de, 2006-10-08: Umbrella issue for editorial fixes/enhancements. | latest change in revision latest |
| fragment-combination |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43> fielding@kiwi.ics.uci.edu, 1999-08-06: See <http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0103>. julian.reschke@greenbytes.de, 2006-10-29: Part of this was fixed in draft 01 (see issue <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i6>). This leaves us with the open issue: 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.. |
latest change in revision latest |
| i19-bodies-on-GET |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i19> Jeff.Mogul@hp.com, 2006-06-22: (See <http://www.w3.org/mid/200606221739.k5MHd3PA013395@pobox-pa.hpl.hp.com>). |
latest change in revision latest |
| i20-default-charsets-for-text-media-types |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i20> mnot@yahoo-inc.com, 2006-05-01: 2616 Section 3.7.1 states; 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. 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). How do these format-specific defaults interact with HTTP's default? Is HTTP really overriding them? 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... duerst@it.aoyama.ac.jp, 2007-10-05: Here is another issue that apparently hasn't yet been listed. The HTTP spec, in section 3.7.1, currently claims that for subtypes of the media type "text", there is a default of iso-8859-1. In actual practice, this is, at best, wishful thinking. It may also pretty much look like it's actually true if you are in Western Europe or in the Americas, but it doesn't apply world-wide. There are tons of Web sites in Asia (and Asia is home to more than half of the World's population) that have no charset, and that are not in iso-8859-1. And browsers in these regions don't expect pages to be iso-8859-1. ... So the text below should be changed to say that data in all character sets SHOULD be labeled, and move the default to historic. Some adequate adjustments should also be made to Section 3.4.1. I'll gladly help with word-smithing. |
latest change in revision latest |
| i21-put-side-effects |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i21> mnot@yahoo-inc.com, 2006-04-03: 2616 specifically allows PUT to have side effects; 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. and it also says (in the context of PUT) If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. 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? I.e., read literally, the above requirement requires a 201 Created when PUT results in *any* resource being created -- even as a side effect. This is IMO unnecessarily constraining, and should be relaxed; e.g., changed to something like "If a new resource is created at the Request-URI, the origin server MUST inform the user agent via the 201 (Created) response." julian.reschke@gmx.de, 2007-10-06: Discussed during the Prague meeting, see <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action06>: Combine to make second sentence dependent upon the first: "If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response." |
latest change in revision latest |
| i22-etag-and-other-metadata-in-status-messages |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i22> julian.reschke@gmx.de, 2006-08-09: (See proposal at <http://greenbytes.de/tech/webdav/#draft-reschke-http-etag-on-write>). |
latest change in revision latest |
| i23-no-store-invalidation |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i23> rousskov@measurement-factory.com, 2005-07-26: 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. For example, the following happens in our test case: 1. Client requests an entity A without using no-store. 2. Cache proxies the transaction and caches the response (entity A). 3. Client requests the same entity A using "Cache-control: no-store". 4. Cache proxies the transaction and does NOT cache the response. 5. Client requests the same entity A again, without using no-store. 6. Cache serves the "old" entity A cached in step #2 above. 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)? If no, should the cache check that response in step #4 does not indicate that cached entity A is stale? I cannot find explicit rules requiring that, but we do have similar rules about 304 and HEAD responses invalidating older cached entities. |
latest change in revision latest |
| i24-requiring-allow-in-405-responses |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i24> fielding@gbiv.com, 2005-06-23: In RFC 2616, 10.4.6 405 Method Not Allowed: 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. 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. I think the above should be modified to s/MUST/MAY/; does anyone here know of a reason not to make that change? julian.reschke@gmx.de, 2007-10-06: Discussed during the Prague meeting, see <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action08>. |
latest change in revision latest |
| i27-put-idempotency |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i27> mnot@yahoo-inc.com, 2005-03-16: It appears that RFC3253 changes the idempotency of PUT; is this allowed? RFC3253 doesn't update or obsolete 2616... 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. Not a huge problem that happens every day, but it's a bit worrisome. julian.reschke@gmx.de, 2007-10-06: Discussed during the Prague meeting, see <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action10>: "Loosen definition of Idempotency as per Roy." -- See <http://tech.groups.yahoo.com/group/rest-discuss/message/7387>: Just ignore the definition of idempotent in RFC 2616. Anything specified in HTTP that defines how the server shall implement the semantics of an interface method is wrong, by definition. What matters is the effect on the interface as expected by the client, not what actually happens on the server to implement that effect. |
latest change in revision latest |
| i28-connection-closing |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i28> joe@manyfish.co.uk, 2005-02-26: The phrase "unless the message is terminated by closing the connection" in Section 4.4 is unnecessary. 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). julian.reschke@gmx.de, 2007-10-06: Discussed during the Prague meeting, see <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action01>. |
latest change in revision latest |
| i29-age-calculation |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i29> rousskov@measurement-factory.com, 2002-08-30: 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 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:
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)
I think it is possible to fix the corrected_initial_age formula to match the intent (note this is the *initial* not *received*
age):
corrected_initial_age = max(
now - date_value, # trust the clock (includes delays)
age_value + now - request_time) # trust Age, add network delays
There is no need for corrected_received_age.
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):
current_age = corrected_initial_age
So, we end up with a single formula for all cases and all times:
current_age = max(now - date_value, age_value + now - request_time) = = now - min(date_value, request_time - age_value)
It even has a clear physical meaning -- the min() part is the conservative estimate of object creation time.
julian.reschke@gmx.de, 2007-10-06: Discussed during the Prague meeting, see <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action11>. |
latest change in revision latest |
| i30-header-lws |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i30> jamie@shareable.org, 2004-03-15: See <http://www.w3.org/mid/20040315183116.GC9731@mail.shareable.org>. |
latest change in revision latest |
| i32-options-asterisk |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i32> julian.reschke@gmx.de, 2003-11-24: 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). julian.reschke@gmx.de, 2007-10-08: Quote Roy Fielding: ...Allow only applies to URIs, not *... |
latest change in revision latest |
| i33-trace-security-considerations |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i33> rousskov@measurement-factory.com, 2003-02-14: There is an HTTP-related security violation approach found/researched by White Hat Security: PR: <http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt> Details: <http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf> I bet many of you have seen the related advisories/PR. For those who have not, here is the gist: 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. 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. What is your opinion? Should TRACE be supported by default? Is it a good idea to mention this "exposure" vulnerability in HTTP errata or elsewhere? |
latest change in revision latest |
| i34-updated-reference-for-uris |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i34> julian.reschke@greenbytes.de, 2006-11-14: Update RFC2396 ("Uniform Resource Identifiers (URI): Generic Syntax") to RFC3986. |
latest change in revision latest |
| i35-split-normative-and-informative-references |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i35> References are now required to be split into "Normative" and "Informative". julian.reschke@gmx.de, 2007-10-12: See related issues: i65-informative-references, i68-encoding-references-normative, i75-rfc2145-normative, rfc1737_informative_and_obsolete, rfc1766_normative, i86-normative-up-to-date-references, rfc2048_informative_and_obsolete, rfc2396_normative, rfc2616bis, rfc2822_normative, unneeded_references, uri_vs_request_uri and usascii_normative. |
latest change in revision latest |
| i37-vary-and-non-existant-headers |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i37> jamie@shareable.org, 2004-02-23: (See <http://www.w3.org/mid/20040223204041.GA32719@mail.shareable.org>). |
latest change in revision latest |
| i38-mismatched-vary |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i38> hno@squid-cache.org, 2006-10-20: When one cached variant has one Vary header, and then another variant is received with a different Vary header. Lets say the first has Vary: Accept-Languageand the second Vary: Accept-Encodingwhat is the appropriate behaviour for a cache? |
latest change in revision latest |
| i39-etag-uniqueness |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i39> henrik@henriknordstrom.net, 2006-10-19: 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... 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. |
latest change in revision latest |
| i40-header-registration |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i40> 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. |
latest change in revision latest |
| i41-security-considerations |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i41> 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? |
latest change in revision latest |
| i50-misc-typos |
edit open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i50> a-travis@microsoft.com, 2006-12-18: (See <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0275.html>). julian.reschke@greenbytes.de, 2007-06-29: Some of the strictly editorial issues have been resolves as part of issue "edit". |
latest change in revision latest |
| i51-http-date-vs-rfc1123-date |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i51> a-travis@microsoft.com, 2006-12-18: On closer inspection, shouldn't the BNF for that section (14.18) be "rfc1123-date" and not "HTTP-date"? I mean, why say it's an HTTP-date, but only RFC 1123 form is allowed (conflicting with the definition of HTTP-date)*? Likewise, shouldn't we just use the rfc1123-date moniker throughout the document whenever explicitly referring to only dates in RFC 1123 format? |
latest change in revision latest |
| i52-sort-1.3-terminology |
edit open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i52> a-travis@microsoft.com, 2006-12-21: It's irritating to try and look up definitions in section 1.3. IMHO, the entries really should be sorted alphabetically, despite the fact that the terms have dependencies on one another. julian.reschke@greenytes.de, 2006-06-15: See action item <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action23> and proposal in <http://lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0350.html>. julian.reschke@greenytes.de, 2006-06-15: I personally think we should not do this change: (1) Sorting paragraphs makes it very hard to verify the changes; in essence, a reviewer would either need to trust us, or re-do the shuffling to control whether it's correct (nothing lost, no change in the definitions). (2) In the RFC2616 ordering, things that belong together (such as "client", "user agent", "server" ...) are close to each other. (3) Contrary to RFC2616, the text version of new spec will contain an alphabetical index section anyway (unless it's removed upon publication :-). |
latest change in revision latest |
| i53-allow-is-not-in-13.5.2 |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i53> a-travis@microsoft.com, 2006-12-20: Section 14.7 states: "A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other means of communicating with the origin server." However, section 13.5.2 (Non-modifiable Headers) makes no mention of Allow. This seems like an error, but I'm not entirely sure what the fix should be -- remove 13.5.2 and push the (not-)modifiable information in the definition of the respective headers, or to maintain 13.5.2 in parallel with all of the header definitions, or to push all the information out of the header definitions into 13.5.2. The easy fix for now would be to just make a mention of Allow in 13.5.2. Additionally, Server should also be included. |
latest change in revision latest |
| i54-definition-of-1xx-warn-codes |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54> a-travis@microsoft.com, 2006-12-22: See <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54>. |
latest change in revision latest |
| i55-updating-to-rfc4288 |
edit open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i55> julian.reschke@gmx.de, 2007-01-05: The update from RFC2048 to RFC4288 requires minor modifications for the media type registrations for "message/http", "application/http" and "multipart/byteranges". |
latest change in revision latest |
| i56-6.1.1-can-be-misread-as-a-complete-list |
edit open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i56> henrik@henriknordstrom.net, 2007-01-11: The second sentence in the first paragraph can on a quick reading be misread as section 10 contains a complete definiton of all possible status codes, where it in reality only has the status codes defined by this RFC. |
latest change in revision latest |
| i57-status-code-and-reason-phrase |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i57> henrik@henriknordstrom.net, 2007-01-11: 6.1.1 is apparently a bit too vague about how applications should parse and process the information, making some implementations parse the reason phrase (probably exact matches on the complete status line, not just status code) to determine the outcome. There should be a SHOULD requirement or equivalent that applications use the status code to determine the status of the response and only process the Reason Phrase as a comment intended for humans. It's true that later in the same section there is a reverse MAY requirement implying this by saying that the phrases in the rfc is just an example and may be replaced without affecting the protocol, but apparently it's not sufficient for implementers to understand that applications should not decide the outcome based on the reason phrase. |
latest change in revision latest |
| i58-what-identifies-an-http-resource |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i58> julian.reschke@gmx.de, 2007-01-23: 3.2.2 really doesn't say what identifies the resource: If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (Section 5.1.2). But it does say what part of the HTTP URL becomes the Request-URI, and that definitively needs to be fixed. |
latest change in revision latest |
| i59-status-code-registry |
edit open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i59> henrik@henriknordstrom.net, 2007-02-18: The IANA status code registry should be referred to. |
latest change in revision latest |
| i60-13.5.1-and-13.5.2 |
edit open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i60> mnot@yahoo-inc.com, 2007-03-30: 13.5.1 and 13.5.2 describe how proxies should handle headers, even though it's in a section entitled "Caching in HTTP." People have a hard time finding them. Would it be helpful to try to separate out the purely intermediary-related material from section 13 to a more appropriate place (e.g., section 8, or a new section)? |
latest change in revision latest |
| i61-redirection-vs-location |
edit open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i61> julian.reschke@gmx.de, 2007-04-19: The first sentence could be understood as if the presence of the "Location" response header always implies some kind of redirection. See also <http://lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0020.html>. |
latest change in revision latest |
| i63-header-length-limit-with-encoded-words |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i63> derhoermi@gmx.net, 2007-05-14: (See <http://lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0050.html>). |
latest change in revision latest |
| i64-ws-in-quoted-pair |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i64> dan.winship@gmail.com, 2007-04-20: I think quoted-pair is broken too. Merging your fix into RFC2616 gives: quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = <any TEXT excluding '"' and '\'> quoted-pair = "\" CHAR CHAR = <any US-ASCII character (octets 0 - 127)>but that means you can do this: HTTP/1.1 200 OK Warning: "Don't misparse \ this: it's really a single header!"(if the receiving implementation follows the recommendations in 19.3 you need to escape the LF instead of the CR, but it's otherwise the same.) RFC 2822 updates RFC 822's quoted-pair rule to disallow CR, LF, and NUL. We should probably make the same change. |
latest change in revision latest |
| i67-quoting-charsets |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i67> maiera@de.ibm.com, 2007-05-23: (See <http://lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0065.html>). |
latest change in revision latest |
| i69-clarify-requested-variant |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69> julian.reschke@gmx.de, 2007-07-13: The spec uses the term "requested variant" in several places (10.2.2 201 Created, 10.2.5 204 No Content, 14.19 ETag, 14.25 If-Modified-Since, 14.28 If-Unmodified-Since). It's quite clear what it means in the context of HEAD/GET, somewhat clear for PUT, but not clear at all for other methods. We really need to clarify this, potentially choosing a different term. fielding@gbiv.com, 2007-08-06: ...Think of variant as the target of a request once URI+Vary-fields is taken into account. It is the resource-as-subdivided-by-negotiation, which was the original definition before it got mixed up in committee. Now, if we add the notion of a method that acts by indirection (PROPFIND), then we merely add that notion to the definition in general. variant The ultimate target resource of a request after indirections caused by content negotiation (varying by request fields) and method association (e.g., PROPFIND) have been taken into account. Some variant resources may also be identified directly by their own URI, which may be indicated by a Content-Location in the response. |
latest change in revision latest |
| i71-examples-for-etag-matching |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i71> julian.reschke@greenbytes.de, 2006-12-02: Add examples for weak and strong matching. julian.reschke@greenbytes.de, 2007-06-07: Backed out example, because it's controversial. We need to answer the question: "Are there circumstances where a server will weakly match the etags "1" and W/"1"? julian.reschke@greenbytes.de, 2007-07-17: Re-added example table for further discussion. |
latest change in revision latest |
| i72-request-method-registry |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i72> henrik@henriknordstrom.net, 2007-08-06: I see a need for an official HTTP request method registry to be established, preferably maintained by IANA. |
latest change in revision latest |
| i73-clarification-of-the-term-deflate |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i73> paul_marquess@yahoo.co.uk, 2007-08-07: There is ambiguity in that definition because of the inconsistent use of the term "deflate". This has resulted in a long standing confusion about how to implement "deflate" encoding. There was a time a few years back when most of the high profile browser and some http server implementations incorrectly implemented http "deflate" encoding using RFC 1951 without the RFC 1950 wrapper. Admittedly most, if not all, of the incorrect implementations have now been fixed, but the fix applied recognises the reality that there are incorrect implementations of "deflate" out in the wild. All browsers now seem to be able to cope with "deflate" in both its RFC1950 or RFC1951 incarnations. So I suggest there are two issues that need to be addressed 1. The definition of "deflate" needs to be rewritten to remove the ambiguity. 2. Document the reality that there are incorrect implementations, and recommend that anyone writing a "deflate" decoder should cope with both forms. |
latest change in revision latest |
| i74-character-encodings-for-headers |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i74> duerst@it.aoyama.ac.jp, 2007-07-10: RFC 2616 prescribes that headers containing non-ASCII have to use either iso-8859-1 or RFC 2047. This is unnecessarily complex and not necessarily followed. At the least, new extensions should be allowed to specify that UTF-8 is used. |
latest change in revision latest |
| i75-rfc2145-normative |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i75> Jeff.Mogul@hp.com, 2007-06-07: http://www.ietf.org/rfc/rfc2145.txt: There are references from RFC2616, section 3.1, to this document. Perhaps these should be marked as normative; certainly, a proxy implemention that violates RFC2145 is non-compliant in any reasonable sense of the word. |
latest change in revision latest |
| i76-deprecate-305-use-proxy |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i76> adrien@qbik.com, 2007-06-15: I can't find any browser that supports this. * IE 6 silently fails (shows blank page, does not attempt connection to proxy). * FF 2 silently fails (shows blank page, does not attempt connection to proxy). * Opera displays message "The server tried to redirect Opera to the alternative proxy "http://xxxxxxxx". For security reasons this is no longer supported." So looks like the main browsers (haven't tried Safari) have de facto deprecated it. Is it an optional code to handle? RFC2616 is extremely sparse in its description of the status code. |
latest change in revision latest |
| i77-line-folding |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i77> fielding@gbiv.com, 2007-01-19: ...I think the spec should reflect the standard, not be artificially restricted by adherence to past revisions of itself. By standard, I mean the measure expected by all of the implementations that are exchanging legitimate communication via HTTP. AFAIK, there are no servers or clients that send legitimate messages with anything other than Field-name: field-valueso it is time for the spec to reflect that fact. My only caveat is that there should be an exception for the message/http media type, such that messages received via SMTP shall allow line folding. ... ...MUST NOT send such LWS is fine, including when a message is forwarded, but forbidding a server from processing such a message is not going to happen because it would make all implementations non-compliant. Servers should be configurable in regards to robust or restricted parsing behavior, and nothing we say can improve the "security" of broken software that was deployed years ago. Software that correctly parses according to the RFC is not subject to those perceived security issues. |
latest change in revision latest |
| i78-relationship-between-401-authorization-and-www-authenticate |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78> hugo@yahoo-inc.com, 2007-07-25: Are these mechanisms exclusive? I.e., can they only be used together, or can a cookie-based authentication scheme (for example) use 401? (full message at <http://www.w3.org/mid/5A4607FB-6F74-4C7F-BF60-37E0EFEC97DF@yahoo-inc.com>) |
latest change in revision latest |
| i79-content-headers-vs-put |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i79> julian.reschke@greenbytes.de, 2007-07-25: It's not clear to me what Content-* headers are? All headers starting with the character sequence "Content-"? Just those defined in RFC2616? |
latest change in revision latest |
| i80-content-location-is-not-special |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i80> julian.reschke@greenbytes.de, 2007-07-31: The definition of Content-Location ends with: "The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases." This was added in RFC2616 (does not appear in RFC2068). I have no problem allowing servers to ignore it. However: 1) It seems that the meaning of Content-Location is universal for messages that carry an entity; I'm not sure what's the point in claiming that meaning does not apply to PUT or POST. 2) Also: every time a limited set of methods is mentioned somewhere it feels like problematic spec writing. What makes PUT or POST so special in comparison to other methods? Maybe that they are the only methods in RFC2616 that carry request entity bodies? In which case the statement should be rephrased accordingly... |
latest change in revision latest |
| i81-content-negotiation-for-media-types |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81> lmm@acm.org, 2006-04-11: HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out. The original theory of content negotiation was worked out when the idea of the web was that browsers would support a handful of media types (text, html, a couple of image types), and so it might be reasonable to send an 'accept:' header listing all of the types supported. But in practice as the web evolved, browsers would support hundreds of types of all varieties, and even automatically locate readers for content-types, so it wasn't practical to send an 'accept:' header for all of the types. So content negotiation in practice doesn't use accept: headers except in limited circumstances; for the most part, the sites send some kind of 'active content' or content that autoselects for itself what else to download; e.g., a HTML page which contains Javascript code to detect the client's capabilities and figure out which other URLs to load. The most common kind of content negotiation uses the 'user agent' identification header, or some other 'x-...' extension headers to detect browser versions, among other things, to identify buggy implementations or proprietary extensions. I think we should deprecate HTTP content negotiation, if only to make it clear to people reading the spec that it doesn't really work that way in practice. Many people seem to use HTTP content negotiation as a motivation for adding 'version' parameters to MIME types or registering new MIME types, with the hopes that the MIME types or parameters would be useful in HTTP content negotiation, and we should warn them that it isn't really productive to do so. That's why it might be useful advice to add to the guidelines for registering MIME types, should those ever be updated. rjgodoy@hotmail.com, 2007-11-03: See http://www.w3.org/mid/BAY118-DAV15B52BB86A84968870D8E0AD8E0@phx.gbl. lmm@acm.org, 2007-11-03: Clearly "deprecate" was hyperbole. (I can say that since I raised the issue in the first place.) However, Accept headers have a limited domain of applicability, e.g., when the client has a limited repertoire of types that it is actually willing to accept, and this is generally not true on typical desktop web browsers (maybe some phones might have such a limitation). The point about changing the 406 requirement so that it matches reality should also be added to the issue. |
latest change in revision latest |
| i83-options-asterisk-and-proxies |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i83> hno@squid-cache.org, 2007-10-01: Text about proxying OPTIONS * contained in RFC2068 was lost in RCF2616. julian.reschke@gmx.de, 2007-10-03: The lost text says: If a proxy receives a request without any path in the Request-URI and the method specified is capable of supporting the asterisk form of request, then the last proxy on the request chain MUST forward the request with "*" as the final Request-URI. For example, the request hno@squid-cache.org, 2007-10-04: ... There is one slight problem with the above and it's " and the method specified is capable of supporting the asterisk form of request". This requires the proxy to know about each such method, and with HTTP being extensible it's not fully possible. In RFC2616 only OPTIONS meets this criteria. Is there a possibility for other methods than OPTIONS which may make sense on a global resource-less context? I think not. If this is complemented with a restriction that the special request-URI "*" may only be used in OPTIONS requests then it's fine. Interoperability of extension methods using "*" will be tricky at best.. ... |
latest change in revision latest |
| i85-custom-ranges |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i85> kornel@geekhood.net, 2007-08-25: The RFC 2616 seems to suggest such possibility in 3.12 Range Units: there's a "other-range-unit" defined. However definition of Content-Range uses "ranges-specifier" and Range uses "content-range-spec", which both seem to allow only byte ranges. In such case, is there any use for "other-range-unit" in Accept-Ranges? LMM@acm.org, 2007-08-31: What I remember was that I pushed for custom ranges and that there was a lot of push-back from people who thought it was too much complexity. I think the idea 'sort of' got into the spec, but not fully fleshed out. I agree that it belongs in the issue list, to either clarify how to use custom ranges (with a range unit registry, for example) or else to remove the feature. |
latest change in revision latest |
| i88-205-bodies |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i88> julian.reschke@greenbytes.de, 2007-11-29: (See <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i88>). |
latest change in revision latest |
| i89-if-dash-and-entities |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i89> henrik@henriknordstrom.net, 2007-10-31: The description of If(-None)-Match still refers to entity when it talks about ETag, should refer to entity tag, variant and requested variant. Sections: 14.24 If-Match 14.26 If-None-Match Problematic text (same in both sections): A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the and later or if "*" is given and any current entity exists for that resource Problem: ETag values is associated with variants, not entities. There is other uses of these conditionals than just simple entity caching which seems to be what the current text has in mind. |
latest change in revision latest |
| i90-delimiting-messages-with-multipart-byteranges |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i90> derhoermi@gmx.net, 2007-11-18: There appears to be some confusion as to when multipart/byteranges bodies have to be inspected to determine the message length. It seems that is widely considered optional and sometimes limited to ... In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception is the "multipart/byteranges" type (appendix 19.2) when it appears in a 206 (Partial Content) response ... ... this particular case, even though the specification suggest the opposite, I read it to say, all implementations have to support that and support it in all messages, like requests and non-206 responses. Apache 2.2.6 for example treats
POST / HTTP/1.1
Host: example
Content-type: multipart/byteranges;
boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
...
as two requests, a zero-length POST and a --THIS_STRING_SEPARATES to the root which it does not support (which seems to
be a bug in itself).
Would it be possible, for example, to discourage implementations to ever generate messages where the message length is determined by this type, and limit having to read it to 206 responses, as the text above suggests? |
latest change in revision latest |
| i91-duplicate-host-header-requirements |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i91> julian.reschke@gmx.de, 2007-11-14: ...any reason why the Host header requirement is listed here so prominently (duplicating text from 14.23)? |
latest change in revision latest |
| i92-empty-host-headers |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i92> derhoermi@gmx.net, 2007-11-21: The specification states "If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value" but the grammar does not seem to allow this. Host = "Host" ":" host [ ":" port ] ; Section 3.2.2should be changed into Host = "Host" ":" [ host [ ":" port ] ] ; Section 3.2.2 |
latest change in revision latest |
| i93-repeating-single-value-headers |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i93> julian.reschke@gmx.de, 2007-11-20: follow-up to a discussion over at the HTML mailing list, see <http://lists.w3.org/Archives/Public/public-html/2007Nov/0271.html>). We currently say in Section 4.2: Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. Now this seems to be kind of backwards, wouldn't it be *much* clearer if it said: Multiple message-header fields with the same field-name MUST NOT be present in a message unless the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. That being said, do we have a recommendation for recipients when that requirement is violated? I would assume that servers SHOULD return a 400 (Bad Request), but what about clients? |
latest change in revision latest |
| i94-reason-phrase-bnf |
change open |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i94> julian.reschke@gmx.de, 2007-11-23: Looking at...: Reason-Phrase = *<TEXT, excluding CR, LF>
TEXT = <any OCTET except CTLs,
but including LWS>
LWS = [CRLF] 1*( SP | HT )
CRLF = CR LF
So was the real intent to say: any OCTET except CTLs?
|
latest change in revision latest |
| languagetag |
change open |
Reference: <http://purl.org/NET/http-errata#languagetag>, <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i13> julian.reschke@greenbytes.de, 2006-10-14: See <http://purl.org/NET/http-errata#languagetag>. julian.reschke@greenbytes.de, 2006-10-14: In the meantime RFC3066 has been obsoleted by RFC4646. See also <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0001>. julian.reschke@greenbytes.de, 2007-11-29: See feedback in <http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0293.html> and <http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0296.html>, in particular the pointer to RFC4647 which defines Language-Range. |
latest change in revision latest |
| link-header |
change open |
Reference: <http://www.w3.org/mid/46DB0738.7090500@gmx.de> julian.reschke@gmx.de, 2007-09-02: The current editor's draft of HTML5 requires User-Agents to respect the HTTP Link header (as specified in RFC2068, and dropped from RFC2616) -- see <http://www.w3.org/html/wg/html5/#the-link>: Some versions of HTTP defined a Link: header, to be processed like a series of link elements. When processing links, those must be taken into consideration as well. For the purposes of ordering, links defined by HTTP headers must be assumed to come before any links in the document, in the order that they were given in the HTTP entity header. Relative URIs in these headers must be resolved according to the rules given in HTTP, not relative to base URIs set by the document (e.g. using a base element or xml:base attributes). [RFC2616] [RFC2068] So either this is just wishful thinking, or implementation support for the Link header has indeed improved lately (I'll guess in FF and Opera). In the latter case, we may want to re-add it in RFC2616bis. |
latest change in revision latest |
| need_iana_considerations |
change open |
julian.reschke@greenbytes.de, 2006-10-24: We need an IANA Considerations section. Include update to HTTP header registration there? (Also: do we need a method name registry?) | latest change in revision latest |
| rfc1737_informative_and_obsolete |
change open |
julian.reschke@greenbytes.de, 2006-10-27: Classify RFC1737 ("Functional Requirements for Uniform Resource Names") as informative and update to RFC2141 ("URN Syntax") which seems to be a better reference. | latest change in revision latest |
| rfc2048_informative_and_obsolete |
edit open |
julian.reschke@greenbytes.de, 2006-11-15:
Classify RFC2048 ("Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures") as informative,
update to RFC4288, potentially update the application/http and multipart/byteranges MIME type registration. Also, in Section
3.7
fix first reference to refer to RFC2046 (it's about media types in general, not the registration procedure).
julian.reschke@greenbytes.de, 2007-04-20: Separate issue for updating the registration template: i55-updating-to-rfc4288. |
latest change in revision latest |
| rfc2616bis |
edit open |
julian.reschke@greenbytes.de, 2006-10-10: Umbrella issue for changes with respect to the revision process itself. | latest change in revision latest |
| rfc2822_normative |
change open |
julian.reschke@greenbytes.de, 2006-12-03:
RFC822 ("STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES") has
been obsoleted by RFC2822 ("Internet Message Format"). Some of the references
from RFC822 can be upgraded, some others are historical notes and should
stay as they are. Also, RFC822 is the base for RFC2616's ABNF; as long
as it has not been upgraded to RFC4234 format, we need to keep RFC822
as normative reference. See issue abnf.
julian.reschke@greenbytes.de, 2007-06-16: RFC4897 requires us to add a note to the references explaining why the downref was made (see <http://tools.ietf.org/html/rfc4897#section-3.1>). |
latest change in revision latest |
| uri_vs_request_uri |
change open |
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0126.html> julian.reschke@greenbytes.de, 2007-01-24: The Request-URI generally is not a URI (when taking any form other than absoluteURI). |
latest change in revision latest |
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| abnf-case-insensitive |
edit closed |
julian.reschke@greenbytes.de, 2007-11-20:
Rule names are case-insensitive. Fix name collisions.
julian.reschke@greenbytes.de, 2007-11-22: Proposal: replace "host" by "uri-host", "trailer" by "trailer-part". |
in revision latest: Done. |
| abnf-chunk-data |
change closed |
julian.reschke@greenbytes.de, 2007-11-22:
The grammar production:
chunk-data = chunk-size(OCTET)doesn't work as intended; "chunk-size" can not appear in this place. Fix the production by moving "chunk-size" into a comment. |
in revision latest: Say "chunk-data = 1*OCTET ; a sequence of chunk-size octets" instead. |
| abnf-dquote |
edit closed |
julian.reschke@greenbytes.de, 2007-11-20: Use DQUOTE instead of <"> in BNF. | in revision latest: Done. |
| abnf-edit |
edit closed |
Reference: <http://www.w3.org/mid/4739C417.2040203@gmx.de> julian.reschke@greenbytes.de, 2007-11-13: Fix minor editorial issues with BNF causing problems with ABNF parsers, such as (1) inconsistent indentation and (2) missing whitespace. |
in revision 04: Done. |
| abnf-prose-cr |
edit closed |
julian.reschke@greenbytes.de, 2007-11-20: Change BNF prose values to not contain line breaks. | in revision latest: Done. |
| abnf-rule-names |
edit closed |
julian.reschke@greenbytes.de, 2007-11-22: Fix invalid rule names: "http_URL" and "abs_path". | in revision latest: Replace "http_URL" by "http-URL" and "abs-path" by "path-absolute" (which is the name used in RFC3986). Also add BNF rules for the other rules imported from RFC2396. |
| charactersets |
change closed |
Reference: <http://purl.org/NET/http-errata#charactersets> Howard@silverstream.com, 2001-02-08: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/2001JanApr/0022.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#charactersets. |
| chunk-size |
change closed |
Reference: <http://purl.org/NET/http-errata#chunk-size> wham_bang@yahoo.com, 1999-06-02: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0018.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#chunk-size. |
| consistent-reason-phrases |
edit closed |
Reference: <http://www.w3.org/mid/472E16C5.8000703@gmx.de> julian.reschke@greenbytes.de, 2007-11-04: Use consistent status reason phrases. |
in revision 04: Done. |
| editor-notes |
edit closed |
Reference: <http://purl.org/NET/http-errata#editor-notes> fielding@kiwi.ics.uci.edu, 1999-08-03: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0102.html. |
in revision 01: Not applicable. New References section is generated by xml2rfc. |
| i25-accept-encoding-bnf |
change closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i25> abodeman@yahoo.com, 2005-06-02: In section 14.3, the definition of Accept-Encoding is given as follows:
Accept-Encoding = "Accept-Encoding" ":"
1#( codings [ ";" "q" "=" qvalue ] )
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:
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
Furthermore, the fourth rule for testing whether a content-coding is
acceptable mentions the possibility that the field-value may be empty.
It seems, then, that the definition for Accept-Encoding should be revised:
Accept-Encoding = "Accept-Encoding" ":"
#( codings [ ";" "q" "=" qvalue ] )
|
in revision 04: Accepted during the Prague meeting, see <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action09>. |
| i26-import-query-bnf |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i26> abodeman@yahoo.com, 2005-05-23: In section 3.2.2, http_URL is defined as follows: http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 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). |
in revision 04: Add "query" to the list of definitions adopted from RCF2396 (note that RFC2396 has been obsoleted by RFC3986, but this is a separate issue). |
| i31-qdtext-bnf |
change closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i31> jamie@shareable.org, 2004-03-15: ...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? |
in revision 04: Resolved as per <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action13>. |
| i45-rfc977-reference |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i45> julian.reschke@greenbytes.de, 2006-10-26: Classify RFC977 (NNTP) as informative, and update the reference to RFC3977. |
in revision 03: Done. |
| i46-rfc1700_remove |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i46> julian.reschke@greenbytes.de, 2006-11-12: RFC1700 ("ASSIGNED NUMBERS") has been obsoleted by RFC3232 ("Assigned Numbers: RFC 1700 is Replaced by an On-line Database"). draft-gettys-http-v11-spec-rev-00 just updates the reference, which I think is a bug. In fact, RFC2616 refers to RCF1700 (1) for the definition of the default TCP port (Section 1.4), (2) for a reference to the character set registry (Section 3.4) and (3) for a reference to the media type registry (Section 3.7). I propose to remove the reference, and to make the following changes: (1) Replace reference with in-lined URL of the IANA port registry, (2) Replace the first reference with the in-lined URL of the IANA character set registry, and drop the second one, and (3) Drop the reference, as the next sentence refers to the Media Type Registration Process anyway. (see also <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0181.html> |
in revision 03: Accepted during the Prague meeting, see http://www.w3.org/2007/03/18-rfc2616-minutes.html#action21. |
| i47-inconsistency-in-date-format-explanation |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i47> julian.reschke@greenbytes.de, 2006-11-20: Should say "...obsolete RFC1036 date format [...]..." instead of "...obsolete RFC 850 [12] date format...". See also <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0187.html>. fielding@gbiv.com, 2007-11-02: The proposed resolution to this issue (in draft 03) is incorrect because RFC1036 doesn't define the date format in question. This was an error introduced in the 2616 editing cycle. It should be fixed by removing reference to 1036, as described below: |
in revision 04: Resolved as proposed by Roy. |
| i48-date-reference-typo |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i48> julian.reschke@greenbytes.de, 2006-11-20: Should say "rfc1123-date format [...]" instead of "[...]-date format". See also <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0186.html> hno@squid-cache.org, 2006-11-29: Better without the [8], making it an internal reference to the grammar. The rfc1123-date is not a copy of RFC1123, only a subset thereof. The relation to RFC 1123 is already well established elsewhere in 3.3.1, including the MUST level requirement on sending the RFC 1123 derived format. A similar RFC 1123 reference which is better replaced by a rfc1123-date grammar reference is also seen in 14.21 Last-Modified. |
in revision 03: Done. |
| i49-connection-header-text |
change closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i49> julian.reschke@greenbytes.de, 2006-12-12: "Other hop-by-hop headers MUST be listed in a Connection header, (section 14.10) to be introduced into HTTP/1.1 (or later)." doesn't really make sense. (See <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0264.html>) Jeff.Mogul@hp.com, 2006-12-12: Proposed rewrite: " Other hop-by-hop headers, if they are introduced either in HTTP/1.1 or later versions of HTTP/1.x, MUST be listed in a Connection header (Section 14.10)." (See <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0265.html>) |
in revision 03: Resolve as proposed by Jeff Mogul in <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0265.html>. |
| i62-whitespace-in-quoted-pair |
change closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i62> dan.winship@gmail.com, 2007-04-20: (...) RFC 2822 updates RFC 822's quoted-pair rule to disallow CR, LF, and NUL. We should probably make the same change. |
in revision 04: Closed as duplicate of i64-ws-in-quoted-pair. |
| i65-informative-references |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i65> julian.reschke@greenbytes.de, 2007-05-28: The following references are informative: Luo1998 ("Tunneling TCP based protocols through Web proxy servers", also update reference to quote the expired Internet Draft properly). Nie1997 ("Network Performance Effects of HTTP/1.1, CSS1, and PNG"). Pad1995 ("Improving HTTP Latency"). RFC821 (SMTP), also update the reference to RFC2821. RFC822 ("STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES") -- but add another instance as RFC822ABNF for the cases where the reference if for the ABNF part (these references will later be replaced by references to RFC4234 (see issue abnf)). RFC959 (FTP). RFC1036 ("Standard for Interchange of USENET Messages"). RFC1123 ("Requirements for Internet Hosts -- Application and Support") -- it is only used as a background reference for rfc1123-date, which this spec defines itself (note this disagrees with draft-gettys-http-v11-spec-rev-00 which made it normative). RFC1305 ("Network Time Protocol (Version 3)"). RFC1436 (Gopher). RFC1630 (URI Syntax) -- there'll be a normative reference to a newer spec. RFC1738 (URL) -- there'll be a normative reference to a newer spec. RFC1806 ("Communicating Presentation Information in Internet Messages: The Content-Disposition Header"). RFC1808 (Relative Uniform Resource Locators). RFC1867 ("Form-based File Upload in HTML"), also update the reference to RFC2388 ("Returning Values from Forms: multipart/form-data"). RFC1900 ("Renumbering Needs Work"). RFC1945 (HTTP/1.0). RFC2026 ("The Internet Standards Process -- Revision 3"). RFC2049 ("Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples"). RFC2068 (HTTP/1.1). RFC2076 ("Common Internet Message Headers"). RFC2110 (MHTML), also update the reference to RFC2557. RFC2145 ("Use and Interpretation of HTTP Version Numbers"). RFC2183 ("Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"). RFC2277 ("IETF Policy on Character Sets and Languages"). RFC2279 (UTF8), also update the reference to RFC3629. RFC2324 (HTCPCP/1.0). Spero ("Analysis of HTTP Performance Problems"). Tou1998 ("Analysis of HTTP Performance"). WAIS ("WAIS Interface Protocol Prototype Functional Specification (v1.5)"). derhoermi@gmx.net, 2007-05-28: On RFC1950-1952: Understanding these documents is required in order to understand the coding values defined for the coding registry established and used by the document; why would it be appropriate to cite them as informative? |
in revision 04: Done (with the exceptions noted by Bjoern Hoehrmann). |
| i66-iso8859-1-reference |
change closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i66> julian.reschke@greenbytes.de, 2006-10-28: Classify ISO8859 as normative, and simplify reference to only refer to ISO8859 Part 1 (because that's the only part needed here), and update to the 1998 version. |
in revision 04: Done. |
| i68-encoding-references-normative |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i68> julian.reschke@greenbytes.de, 2007-05-28: Classify RFC1950 (ZLIB), RFC1951 (DEFLATE) and RFC1952 (GZIP) as normative (note this disagrees with draft-gettys-http-v11-spec-rev-00 which made it informative). julian.reschke@greenbytes.de, 2007-06-16: RFC4897 requires us to add notes to the references explaining why the downref was made (see <http://tools.ietf.org/html/rfc4897#section-3.1>). |
in revision 04: Done. |
| i70-cacheability-of-303 |
change closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i70> fielding@gbiv.com, 2007-07-12: On the cacheability requirement: ... I have no idea why the specification says that. Cache-control can be used to override it. A response received with any other status code MUST NOT be returned in a reply to a subsequent request unless there are Cache-Control directives or another header(s) that explicitly allow it. For example, these include the following: an Expires header (section 14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public" or "private" Cache-Control directive (section 14.9). It looks like the contradiction was added to RFC 2616 when somebody decided to convert the commentary on its use with POST into a fixed requirement on all 303 responses. It is just a bug in the spec. fielding@gbiv.com, 2007-07-13: My suggestion is to change the entire section to: 10.3.4. 303 See Other The server directs the user agent to a different resource, indicated by a URI in the Location header field, that provides an indirect response to the original request. The user agent MAY perform a GET request on the URI in the Location field in order to obtain a representation corresponding to the response, be redirected again, or end with an error status. The Location URI is not a substitute reference for the originally requested resource. The 303 status is generally 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 requested resource does not have a representation of its own that can be transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such that the follow-on representation may be useful without implying that that it adequately represents the previously requested 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 and thus entirely determined by the resource owner(s). A 303 response SHOULD NOT be cached unless it is indicated as cacheable by Cache-Control or Expires header fields. Except for responses to a HEAD request, the entity of a 303 response SHOULD contain a short hypertext note with a hyperlink to the Location URI. dbooth@hp.com, 2007-07-03: ... s/The Location URI indicates/The Location URI SHOULD indicate/ ... dbooth@hp.com, 2007-10-04: ...My thinking was that the owner of the URI originally requested may not be the same as the owner of the redirect URI, and hence the first owner might not have control over whether the resource at the redirect URI really *is* "descriptive of the requested resource", even though it is thought to be. BTW, I do notice one other thing. I suggest changing the following sentence: A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be transferred by the server over HTTP. to: A 303 response to a GET request indicates that the requested resource does not have a representation of its own, available from the request URI, that can be transferred by the server over HTTP. The reason is that if the same resource were requested via a different URI, it might indeed provide a representation of its own (if it were an information resource). The original text would have prevented 303 URIs from identifying information resources, rather than permitting them to identify any kind of resource. fielding@gbiv.com, 2007-10-16: ... In which case it would be redirected via a 301, 302, or 307. 303 only redirects to different resources, which means the requested resource for the 303 response is different from the target resource, even if that difference can't be measured in bits. Even if they aren't, in fact, different, the client is being told by the server that they should be interpreted as different, and that makes it fact as far as HTTP's interface is concerned. There is no information resource in HTTP, for the same reason that there is no spoon in the Matrix. |
in revision latest: |
| i82-rel_path-not-used |
change closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i82> julian.reschke@gmx.de, 2007-10-07: RFC2616 changed the ABNF for http_URL so that it doesn't use rel_path (as defined in RFC2396) anymore. However, that definition is still "adopted" in: URIs in HTTP can be represented in absolute form or relative to some known base URI [11], depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and "authority" from that specification. ...and used in: We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. See Section 9.1.1 for related information. Proposal: 1) get rid of the mention in 3.2.1, and 2) in 13.9 paragraph 2, replace "...query URLs (those containing a "?" in the rel_path part)..." by "...URLs containing a query part..." |
in revision latest: Closed as proposed. |
| i84-redundant-cross-references |
change closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i84> fielding@gbiv.com, 2007-09-28: RFC 2616 sections 9.5 (POST) and 9.6 (PUT) have the following useless waste of bits POST requests MUST obey the message transmission requirements set out in section 8.2. and PUT requests MUST obey the message transmission requirements set out in section 8.2. respectively. They can be safely deleted without changing HTTP. Section 8.2 is not specific to PUT and POST. Likewise, a content-free forward pointer to just one of the many subsections on security consideration is a total waste of brain cells. Those are just two examples of what can only be described as a spaghetti style of content-free cross-references within the spec that make it very hard to read. They should be removed in general at the editors' discretion. |
in revision 04: Remove text as proposed. |
| i86-normative-up-to-date-references |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i86> julian.reschke@greenbytes.de, 2006-11-12: Classify RFC1864 ("The Content-MD5 Header Field") as normative. Note that note this disagrees with draft-gettys-http-v11-spec-rev-00 which made it informative. julian.reschke@greenbytes.de, 2006-11-14: Classify RFC2045 ("Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies") as normative. julian.reschke@greenbytes.de, 2006-11-12: Classify RFC2046 ("Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types") as normative. julian.reschke@greenbytes.de, 2006-11-12: Classify RFC2047 ("MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text") as normative. julian.reschke@greenbytes.de, 2006-10-27: Classify RFC2119 (Key words for use in RFCs to Indicate Requirement Levels) as normative. julian.reschke@greenbytes.de, 2006-10-27: Classify RFC2617 (HTTP Authentication) as normative. |
in revision 04: Done. |
| i87-typo-in-13.2.2 |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i87> fielding@gbiv.com, 2007-09-07: This typo is still in the current draft. s/ought to used/ought to be used/; |
in revision 04: Fixed. |
| identity |
change closed |
Reference: <http://purl.org/NET/http-errata#identity> LMM@acm.org, 2001-11-05: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/2001SepDec/0018.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#identity. |
| ifrange206 |
change closed |
Reference: <http://purl.org/NET/http-errata#identity> rousskov@measurement-factory.com, 2003-04-15: See http://lists.w3.org/Archives/Public/ietf-http-wg/2003AprJun/0003.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#ifrange206. |
| invalidupd |
change closed |
Reference: <http://purl.org/NET/http-errata#invalidupd> Jeff.Mogul@hp.com, 2002-06-21: See http://lists.w3.org/Archives/Public/ietf-http-wg/2002AprJun/0058.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#invalidupd. |
| location-fragments |
change closed |
Reference: <http://purl.org/NET/http-errata#location-fragments> fielding@kiwi.ics.uci.edu, 1999-08-06: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0103. julian.reschke@greenbytes.de, 2006-10-16: Fix BNF and add note about when it's appropriate to use fragments as suggested in http://purl.org/NET/http-errata#location-fragments. This leaves us with the open issue: 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.. |
in revision 02: Close this issue (with fixes in draft 01), and add the new issue fragment-combination to deal with the remaining issue. |
| media-reg |
change closed |
Reference: <http://purl.org/NET/http-errata#media-reg>, <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i8> derhoermi@gmx.net, 2000-09-10: See <http://lists.w3.org/Archives/Public/ietf-http-wg-old/2000SepDec/0013>. |
in revision 04: Done (note that RFC2048 has been obsoleted now as well; see separate issue rfc2048_informative_and_obsolete). Note that the prosed resolution in <http://purl.org/NET/http-errata#media-reg> contains typos both in the original text ("4288" rather than "1590") and in the proposed resolution ("Mulitpurpose"). |
| msg-len-chars |
edit closed |
Reference: <http://purl.org/NET/http-errata#msg-len-chars> fielding@kiwi.ics.uci.edu, 1999-08-03: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0102.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#msg-len-chars. |
| noclose1xx |
change closed |
Reference: <http://purl.org/NET/http-errata#noclose1xx> fielding@ebuilt.com, 2001-11-08: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/2001SepDec/0022.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#noclose1xx. |
| post |
change closed |
Reference: <http://purl.org/NET/http-errata#post> mogul@pa.dec.com, 2002-04-09: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/2002JanApr/0024.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#post. |
| references_style |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0182.html> julian.reschke@greenbytes.de, 2006-11-12: Change references style to symbolic ("[RFC2396]") instead of ("[42]"). |
in revision 02: Done. |
| remove-CTE-abbrev |
edit closed |
Reference: <file:///C:/projects/w3c/WWW/Protocols/HTTP/1.1/rfc2616bis/issues/index.html#i16> fielding@gbiv.com, 2007-11-02: ...there is absolutely no reason to abbreviate the field name when it is only used twice in the entire document... |
in revision 04: Done. |
| rfc1766_normative |
edit closed |
julian.reschke@greenbytes.de, 2006-11-15: Classify RFC1766 ("Tags for the Identification of Languages") as normative (update to RFC4646 in a separate step, see issue languagetag). | in revision 04: Done. |
| rfc2396_normative |
edit closed |
julian.reschke@greenbytes.de, 2006-11-13: Classify RFC2396 ("Uniform Resource Identifiers (URI): Generic Syntax") as normative (update to RFC3986 in a separate step, see i34-updated-reference-for-uris). | in revision 04: Done. |
| rfc2606-compliance |
edit closed |
Reference: <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i42> julian.reschke@greenbytes.de, 2006-10-19: Make sure that domain names in examples use names reserved for that purpose (see RFC2606). |
in revision 02: Done. |
| saferedirect |
change closed |
Reference: <http://purl.org/NET/http-errata#saferedirect> fielding@ebuilt.com, 2001-03-03: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/2001JanApr/0031.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#saferedirect. |
| trailer-hop |
edit closed |
Reference: <http://purl.org/NET/http-errata#trailer-hop> mogul@pa.dec.com, 2000-12-04: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/2000SepDec/0127.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#trailer-hop. |
| unneeded_references |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0054>, <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i44> julian.reschke@greenbytes.de, 2006-10-19: The reference entries for RFC1866, RFC2069 and RFC2026 are unused. Remove them? julian.reschke@greenbytes.de, 2006-11-02: See also <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0118>. |
in revision 04: Remove references to RFC1866 and RFC2069 for now. Keep RFC2026 for now; it's referenced from Editorial note. |
| unsafe-uri |
change closed |
Reference: <http://purl.org/NET/http-errata#unsafe-uri> fielding@kiwi.ICS.UCI.EDU, 1999-09-10: See http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1999/0273.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#unsafe-uri. |
| uriquery |
change closed |
Reference: <http://purl.org/NET/http-errata#uriquery> LMM@acm.org, 2001-07-30: See http://lists.w3.org/Archives/Public/ietf-http-wg-old/2001MayAug/0034.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#uriquery. |
| usascii_normative |
edit closed |
julian.reschke@greenbytes.de, 2006-10-27: Classify USASCII as normative. | in revision 04: Done. |
| verscase |
change closed |
Reference: <http://purl.org/NET/http-errata#verscase> fielding@apache.org, 2002-09-16: See http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/0066.html. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#verscase. |
| via-must |
change closed |
Reference: <http://purl.org/NET/http-errata#via-must> julian.reschke@greenbytes.de, 2006-10-14: See http://purl.org/NET/http-errata#via-must. |
in revision 01: Resolved as per http://purl.org/NET/http-errata#via-must. |
| Version | Issues |
|---|---|
| latest | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 04 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 03 | |||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 02 | ||||||||||||||||||||||||| |
| 01 | |||||||||||||||||||||| |
| 00 | || |
Last change: 2007-11-29