RFC Errata
Found 6 records.
Status: Verified (2)
RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005
Note: This RFC has been updated by RFC 6874, RFC 7320, RFC 8820
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 2525
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Yeleighton
Date Reported: 2010-09-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12
Section 3.1 says:
Advice for designers of new URI schemes can be found in [RFC2718].
It should say:
Advice for designers of new URI schemes can be found in [RFC4395].
Notes:
The document [RFC2718] is for designers of designers of new URL schemes only. It has been obsoleted by [RFC4395] that covers all URI schemes.
[RFC4395]
T. Hansen, T. Hardie, T. and L. Masinter,
"Guidelines and Registration Procedures for New URI Schemes",
RFC 4395, February 2006.
Errata ID: 7590
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Kallus
Date Reported: 2023-08-06
Verifier Name: Orie Steele
Date Verified: 2024-03-29
Section 5.2.4 says:
N/A
It should say:
N/A
Notes:
The "1" in step 1 of the second example for "remove_dot_segments" has an unintentional hyperlink to section 1 of the document. The hyperlink should be removed.
Status: Reported (4)
RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005
Note: This RFC has been updated by RFC 6874, RFC 7320, RFC 8820
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 4547
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: siva elango ramaswamy
Date Reported: 2015-12-01
Section 5.4.2 says:
5.4.2. Abnormal Examples
Although the following abnormal examples are unlikely to occur in
normal practice, all URI parsers should be capable of resolving them
consistently. Each example uses the same base as that above.
Parsers must be careful in handling cases where there are more ".."
segments in a relative-path reference than there are hierarchical
levels in the base URI's path. Note that the ".." syntax cannot be
used to change the authority component of a URI.
"../../../g" = "http://a/g"
"../../../../g" = "http://a/g"
It should say:
5.4.2. Abnormal Examples
Although the following abnormal examples are unlikely to occur in
normal practice, all URI parsers should be capable of resolving them
consistently. Each example uses the same base as that above.
Parsers must be careful in handling cases where there are more ".."
segments in a relative-path reference than there are hierarchical
levels in the base URI's path. Note that the ".." syntax cannot be
used to change the authority component of a URI.
"../../../g" = "http://a/../g"
"../../../../g" = "http://a/../../g"
Notes:
The example which was taken from RFC 1808 had proper resolved URL ( 5.2 ).
As the base URL has two levels ( http://a/b/c/ ) and if the relative url's have two ".." segments then from the resolved URI both the hierarchical levels can be removed to form the resolved URL, as below:
../../g = http://a/g
and if there are more ".." segments than hierarchical level in base URI's path... then the number of ".." segments that doesn't have corresponding segments in base URI should be left as is in the resolved URI, like below
"../../../g" = "http://a/../g"
Errata ID: 4789
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dinar Qurbanov
Date Reported: 2016-08-31
Section 5.2.3 says:
o If the base URI has a defined authority component and an empty
path, then return a string consisting of "/" concatenated with the
reference's path; otherwise,
It should say:
o If the base URI has a defined authority component and an empty
path, or if the base URI's path is ending with "/..", then return
a string consisting of base's path concatenated with "/" and then
concatenated with the reference's path; otherwise,
Notes:
this is about case when reference does not have scheme and authority and its path is not starting with "/".
Errata ID: 4942
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: r. de raat
Date Reported: 2017-02-19
Section 3.2.2. Host says:
Such a name consists of a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters. The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain. reg-name = *( unreserved / pct-encoded / sub-delims ) If the URI scheme defines a default for host, then that default
It should say:
Such a name consists of a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters. The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain. reg-name = *( unreserved / pct-encoded / "-" / ".") If the URI scheme defines a default for host, then that default
Notes:
sub-delims are defined as "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" these are not characters that are allowed in host, domain or tld names, in addition the sub-delims do not sontain the "-" and "."
therefore the reg-name (fully qualified domain name) definition is incorrect
The same issue appears in "Appendix A."
Errata ID: 5428
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kevin Layer
Date Reported: 2018-07-17
Section 4.2 says:
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
It should say:
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-abempty ; this was added
/ path-empty
Notes:
As written, the ABNF excludes "/" being a valid URI. It is hard to believe that href="/" when converted to a URI, would be illegal.