RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 16 records.

Status: Verified (1)

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 GROUP
Area 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.

Status: Reported (5)

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 GROUP
Area 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.

Errata ID: 7590
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Kallus
Date Reported: 2023-08-06

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: Held for Document Update (3)

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 GROUP
Area Assignment: app

Errata ID: 2624
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Peter Saint-Andre
Date Reported: 2010-11-11
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-03-30

Section Appendix B says:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

It should say:

/^(([^:\/?#]+):)?(\/\/([^\/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?/

Notes:

This is a copy of Erratum #1933, reported against RFC 2396.

Errata ID: 2033
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Tanaka Akira
Date Reported: 2010-02-05
Held for Document Update by: Alexey Melnikov

Section 3.3. says:

      path-empty    = 0<pchar>

It should say:

      path-empty    = ""

Notes:

According to ABNF, 0<pchar> is interpreted as
zero repeatation of the prose-val: pchar.

However pchar is an non-terminal.
So I think the production should be follows:
path-empty = 0pchar

However this production means a empty string.
So
path-empty = ""
is more clear.

Appendix A. has also the same production.

Errata ID: 2933
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Bjoern Hoehrmann
Date Reported: 2011-08-13
Held for Document Update by: Peter Saint-Andre
Date Held: 2012-02-27

Section 5.2.2. says:

T.path = merge(Base.path, R.path);

It should say:

T.path = merge(Base, R);

Notes:

In 5.2.3. the "If the base URI has a defined authority component" condition requires knowing the authority component, so passing just the path component is misleading.

During discussion of this issue, Roy Fielding noted: "No, this is not an error in the algorithm. The algorithm is just saying that you need to merge the two paths. The two paths are not parameters to a function, nor is the merge procedure limited to those two parameters." Saving this report as "Hold For Document Update" so that future implementers do not experience the same confusion.

Status: Rejected (7)

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 GROUP
Area Assignment: app

Errata ID: 3330
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: David Sheets
Date Reported: 2012-08-29
Rejected by: Barry Leiba
Date Rejected: 2012-09-04

Section Appendix A says:

fragment      = *( pchar / "/" / "?" )

It should say:

fragment      = *( pchar / "/" / "?" / "#" )

Notes:

Appendix B's regex doesn't fail with this correction. Additionally, this gives freedom to media type designers. Specifically, the ((path?),(query?),(fragment?)) subsyntax could be reused in hypermedia type design as the "?" delimiter transitions path => query and the "#" delimiter transitions query => fragment. It also follows the pattern:
path = *( pchar / "/" )
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" / "#" )
--VERIFIER NOTES--
This is something that should be looked at further, but it is not an error in the spec and is unlikely to be a direct change we'd make in a revision of the spec.

Some applications at the time the specification was written parsed the fragment from left to right, and others parsed from right to left, which means they would get different results if "#" were allowed inside of a fragment. That's why it was not allowed in the ABNF. It's possible that situation has improved in the years since, but it would be difficult to test so many implementations. Deciding the right way to handle this goes beyond what can be handled by an erratum.

Errata ID: 4293
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Cesar Crusius
Date Reported: 2015-03-07
Rejected by: Barry Leiba
Date Rejected: 2015-03-07

Section Appendix B says:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

It should say:

^(([^:/?#]+):)(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

Notes:

The regular expression makes the scheme part optional, but both the ABNF in Appendix A and the text in Section 3 state that the scheme is in fact required.
--VERIFIER NOTES--
The context is that this is for parsing references:

The following line is the regular expression for breaking-down a
well-formed URI reference into its components.

The ABNF makes it clear that the scheme is, in fact, NOT required for URI references (see the ABNF for the "relative-ref" production).

Errata ID: 4393
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Steven Liekens
Date Reported: 2015-06-15
Rejected by: Barry Leiba
Date Rejected: 2015-06-15

Section 3.2.2 says:

dec-octet   = DIGIT                 ; 0-9
            / %x31-39 DIGIT         ; 10-99
            / "1" 2DIGIT            ; 100-199
            / "2" %x30-34 DIGIT     ; 200-249
            / "25" %x30-35          ; 250-255

It should say:

dec-octet = "25" %x30-35          ; 250-255
          / "2" %x30-34 DIGIT     ; 200-249
          / "1" 2DIGIT            ; 100-199
          / %x31-39 DIGIT         ; 10-99
          / DIGIT                 ; 0-9

Notes:

The 'dec-octet' rule requires more than 1 lookahead symbol.

Example value: 127

Parsers that implement a first-match-wins strategy will erroneously match 127 as ( DIGIT ), followed by two unexpected symbols.

Parsers that implement a first-match-wins strategy with the corrected grammar will correctly match 127 as ( "1" 2DIGIT ).
--VERIFIER NOTES--
Yes, except that ABNF defined in RFC 5234 is designed to describe what's valid to produce -- it's not designed as the definitive source for building a perfect parser. In particular, the order of the alternatives is not significant in ABNF, so reordering them is irrelevant.

In fact, the ABNF here is more specific than it often is. In other RFCs it will say things like
xyz = 0 / %x31-39 *2DIGIT ; valid values are 0-255
...and just let the comment restrict the maximum value.

Errata ID: 4394
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Steven Liekens
Date Reported: 2015-06-15
Rejected by: Barry Leiba
Date Rejected: 2015-06-15

Section 3.2.2 says:

IPv6address =                            6( h16 ":" ) ls32
                 /                       "::" 5( h16 ":" ) ls32
                 / [               h16 ] "::" 4( h16 ":" ) ls32
                 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                 / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                 / [ *4( h16 ":" ) h16 ] "::"              ls32
                 / [ *5( h16 ":" ) h16 ] "::"              h16
                 / [ *6( h16 ":" ) h16 ] "::"

It should say:

IPv6address = (                6( h16 ":" ) ls32 ) 
            / (           "::" 5( h16 ":" ) ls32 )
            / ( [   h16 ] "::" 4( h16 ":" ) ls32 )
            / ( [ h16-2 ] "::" 3( h16 ":" ) ls32 )
            / ( [ h16-3 ] "::" 2( h16 ":" ) ls32 )
            / ( [ h16-4 ] "::"    h16 ":"   ls32 )
            / ( [ h16-5 ] "::"              ls32 )
            / ( [ h16-6 ] "::"               h16 )
            / ( [ h16-7 ] "::"                   )

h16-7       = ( *6( h16 ":" ) h16 ) / h16-6

h16-6       = ( *5( h16 ":" ) h16 ) / h16-5

h16-5       = ( *4( h16 ":" ) h16 ) / h16-4

h16-4       = ( *3( h16 ":" ) h16 ) / h16-3

h16-3       = ( *2( h16 ":" ) h16 ) / h16-2

h16-2       = (   [ h16 ":" ] h16 ) / h16

Notes:

The 'IPv6address' rule requires more than 1 lookahead symbol.

Example value: 1::

Parsers that implement a first-match-wins strategy will erroneously match 1:: as ( h16 ":" ), followed by an unexpected symbol.

Parsers that implement a first-match-wins strategy with the corrected grammar will correctly match 1:: as ( h16 "::" ).
--VERIFIER NOTES--
As with errata report 4393, this is trying to use ABNF beyond what it's meant for.

Errata ID: 7019
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Tim McSweeney
Date Reported: 2022-07-10
Rejected by: Francesca Palombini
Date Rejected: 2022-07-12

Section B says:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

It should say:

^(([^:/?#]+):#)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

Notes:

Added the missing '#" delimiter.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported error is not an error, but a deliberate decision of the authors and working group. The change, therefore, if it is to be applied needs to be achieved through a consensus document and definitely not via an errata report.

Errata ID: 1783
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Christopher Yeleighton
Date Reported: 2009-05-15
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15

Section 3.1. says:

Advice for designers of new URI schemes can be found in [RFC2718].

It should say:

Advice for designers of new URL schemes can be found in [RFC2718].

Notes:

[RFC2718] does not contain advice for designers of new URN schemes; it is applies to URL schemes only and it is titled accordingly.
The information as published is misleading.
--VERIFIER NOTES--
Given that RFC 4395 ("Guidelines and Registration Procedures for New URI Schemes") obsoletes the referenced RFC 2718 ("Guidelines for new URL Schemes"), this erratum is best considered in error.

Errata ID: 2717
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Winfred Qin
Date Reported: 2011-02-14
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-16

Section 3 says:

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

It should say:

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-noscheme
                  / path-rootless
                  / path-empty

Notes:

There are four ABNF rules for path, but the following words says:

'These restrictions result in five different ABNF rules for a path (Section 3.3)'

And in section 3.3, there are five rules.
--VERIFIER NOTES--
PSA: There is no error here, because the hierarchical part excludes
paths that are not preceded by "//", whereas the path rule includes
paths that are not preceded by "//" (thus five rules for "path" but
only four rules for "hier-part").

Report New Errata



Advanced Search