RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 19 records.

Status: Verified (1)

RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 4225
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Bjoern Hoehrmann
Date Reported: 2015-01-09
Verifier Name: Barry Leiba
Date Verified: 2015-01-17

Section A. C & A. D says:

     field-name    = <comment, see [RFC7230], Section 3.2>

It should say:

     field-name    = <field-name, see [RFC7230], Section 3.2>

Notes:

field-name does not follow the `comment` production. The section number is correct.

Status: Held for Document Update (6)

RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

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

Reported By: Daurnimator
Date Reported: 2016-05-10
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Section 3.1.1.2 says:

3.1.1.2.  Charset

   HTTP uses charset names to indicate or negotiate the character
   encoding scheme of a textual representation [RFC6365].  A charset is
   identified by a case-insensitive token.

     charset = token

   Charset names ought to be registered in the IANA "Character Sets"
   registry (<http://www.iana.org/assignments/character-sets>) according
   to the procedures defined in [RFC2978].

It should say:

3.1.1.2.  Charset

   HTTP uses charset names to indicate or negotiate the character
   encoding scheme of a textual representation [RFC6365].


     charset       = <mime-charset, see [RFC5987], Section 3.2.1>


   Charset names ought to be registered in the IANA "Character Sets"
   registry (<http://www.iana.org/assignments/character-sets>) according
   to the procedures defined in [RFC2978].

Notes:

The definition of charset from RFC 5987 is more strict and more correct.

Mark Nottingham: This is not an errata; it is a suggestion for a technical change in the document, and needs to be discussed by the working group.

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

Reported By: Danil Suits
Date Reported: 2018-11-02
Held for Document Update by: Alexey Melnikov
Date Held: 2019-03-20

Section 4.3.5 says:

If a DELETE
   request passes through a cache that has one or more stored responses
   for the effective request URI, those stored responses will be
   invalidated

It should say:

If a successful DELETE
   request passes through a cache that has one or more stored responses
   for the effective request URI, those stored responses will be
   invalidated

Notes:

RFC 7234 4.4 describes the semantics of cache invalidation for successful requests (non-error status code), but does not describe semantics for unsuccessful requests. The corrected text parallels the construction in section 4.3.4 ("If a successful PUT request...").

Mark Nottingham wrote:

I think HOLD FOR UPDATE; we can address this in the current http-core work.

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

Reported By: Anders Kaseorg
Date Reported: 2019-08-12
Held for Document Update by: Francesca Palombini
Date Held: 2021-08-23

Section 4.3.7 says:

A server MUST generate a Content-Length field with a value of "0" if no
payload body is to be sent in the response.

It should say:

If no payload body is to be sent in the response, a server MUST
generate a status code of 204 (No Content) or a Content-Length field
with a value of "0" (but not both).

Notes:

The original text contradicts RFC 7230 §3.3.2: “A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content)”, unless the intention was to disallow all 204 responses to OPTIONS requests, which I assume it was not.

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

Reported By: Martin Thomson
Date Reported: 2014-08-06
Held for Document Update by: Barry Leiba
Date Held: 2014-08-06

Section TOC says:

ed 

Notes:

Three extraneous characters "ed " appear before the table of contents entry for 7.1.1.

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

Reported By: Aron Duby
Date Reported: 2015-08-06
Held for Document Update by: Barry Leiba
Date Held: 2015-08-07

Section 4.3.5 says:

If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted, a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied,
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

It should say:

If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted; a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied;
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

Notes:

Using a semicolon creates a stronger delineation of the different options. If you are just quickly trying to parse what status to return if the delete hasn't happened yet and you quickly read "has not yet been enacted, a 204 (No Content)" you could incorrectly read that as return a 204. The semicolon makes it more obvious that "enacted" is the end of that thought and to scan backwards where as the comma in this instance requires knowing the structure of the rest of the paragraph.

----- Verifier Notes -----
There's no reason to use semicolons to delimit this list, because the list items themselves don't contain commas. Still, the reporter's confusion is noted. Perhaps a bullet list would be better in this case:

-------
If a DELETE method is successfully applied, the origin server SHOULD
send

- a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted,

- a 204 (No Content) status code if the action has been enacted and
no further information is to be supplied, or

- a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.
-------

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

Reported By: Attila Gulyas
Date Reported: 2015-08-22
Held for Document Update by: Barry Leiba
Date Held: 2015-08-22

Section 6.4 says:

Automatic redirection needs to done with
   care for methods not known to be safe, as defined in Section 4.2.1,
   since the user might not wish to redirect an unsafe request.

It should say:

Automatic redirection needs to be done with
   care for methods not known to be safe, as defined in Section 4.2.1,
   since the user might not wish to redirect an unsafe request.

Notes:

A simple typo ("needs to _be_ done")

Status: Rejected (12)

RFC 7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", June 2014

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

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

Reported By: Anne van Kesteren
Date Reported: 2014-06-30
Rejected by: Barry Leiba
Date Rejected: 2014-07-01

Section 3.1.1.1 says:

media-type = type "/" subtype *( OWS ";" OWS parameter )

It should say:

media-type = type "/" subtype *( OWS ";" OWS [parameter] )

Notes:

See the thread at http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0027.html

Implementations are much more relaxed when it comes to parsing MIME types.

The above is probably still too strict. E.g. requiring that a parameter contains "=" is something I doubt is actually the case in practice.
--VERIFIER NOTES--
The ABNF is there to specify what the expected productions are, and is correct as it stands: we do not *want* things such as these to be produced:

Content-Type: text/plain;
Content-Type: text/plain; charset=iso8859-1;
Content-Type: text/plain;;;;;;;;;;;; ;;; ;;; ;;;

That said, this report addresses a real problem: lack of direction to parsers on how to be appropriately lenient. Because the fact is that general interoperability of this stuff in the wild would be improved if parsers accepted at least the first two of the examples above, which are illegal by the grammar, but which do get generated by less-than-perfect implementations.

I'm marking this report as "Rejected" because the problem it means to address is much broader than this one case, and can't be fixed with an errata report. But it's important that we take up work on a document that does properly address this issue.

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

Reported By: Michel Albert
Date Reported: 2014-11-14
Rejected by: Barry Leiba
Date Rejected: 2014-11-14

Section 6.4 says:

n/a

It should say:

n/a

Notes:

The section on status code 304 is missing even though that status code is mentioned in other parts of the document. RFC2616 described the status code as follows (in section 10.3.5):


> 10.3.5 304 Not Modified
>
> If the client has performed a conditional GET request and access is
> allowed, but the document has not been modified, the server SHOULD
> respond with this status code. The 304 response MUST NOT contain a
> message-body, and thus is always terminated by the first empty line
> after the header fields.
>
> The response MUST include the following header fields:
>
> - Date, unless its omission is required by section 14.18.1


This section would go right after "6.4.4. 303 See Other".
--VERIFIER NOTES--
Status code 304 relates to conditional requests, and is therefore documented in RFC 7232 (Section 4.1). This fact is shown in the table in RFC 7231, Section 6.1, and in the IANA registry "HTTP Status Codes" <http://www.iana.org/assignments/http-status-codes>.

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

Reported By: Christopher Olson
Date Reported: 2015-01-14
Rejected by: Barry Leiba
Date Rejected: 2015-01-17

Section 7.1.1.1 says:

GMT

It should say:

+0000

Notes:

The text refers to RFC 5322. There Sect 3.3 calls the use timezone abbreviations, like GMT, obsolete. It encourages using a numeric offset such as +0000.

The grammar for dates in 7231 Sect 7.1.1.1 uses GMT. Example dates throughout this RFC and others related to HTTP use GMT. This is inconsistent with 5322.

The RFCs for HTTP need to be modified to match 5322, or 7.1.1.1 needs a note that HTTP deliberately deviates from 5322 with regards to the timezone.
--VERIFIER NOTES--
The document is quite clear that the "GMT" version is preferred, and is necessary for compatibility with earlier versions and implementations.

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

Reported By: Nicolas Williams
Date Reported: 2015-04-29
Rejected by: Barry Leiba
Date Rejected: 2015-06-01

Section 4.3.6 says:

   A server MUST NOT send any Transfer-Encoding or Content-Length header
   fields in a 2xx (Successful) response to CONNECT.  A client MUST
   ignore any Content-Length or Transfer-Encoding header fields received
   in a successful response to CONNECT.

   A payload within a CONNECT request message has no defined semantics;
   sending a payload body on a CONNECT request might cause some existing
   implementations to reject the request.

It should say:

   Historically no semantics have been defined for request and 2xx
   (Successful) response bodies for CONNECT, but nonetheless some
   clients and some servers do use request and 2xx response bodies.

   Servers MUST NOT send a response body in a 2xx (Successful)
   response to CONNECT.  Because some proxies send an initial flight
   of tunneled application data in 2xx response bodies, clients MUST
   accept response bodies in 2xx responses to CONNECT, and MUST
   treat the response body as the initial flight of application data.

   Servers that receive a CONNECT request body SHOULD treat it as the
   initial flight of tunneled application data.

Notes:

Implementing the original text ("A client MUST ignore...") has the effect
that the client will leave in the lower layer's buffer any 2xx CONNECT
response body, and when the Transfer-Encoding is the identity, then this
will have the effect that the 2xx response body is seamlessly prepended
to the tunneled application data in the server-to-client direction.
It seems almost like this was the intent of the original text, but if so,
then it would be much better to state this than to describe one possible
implementation approach.

Also, it seems rather unlikely that ignoring the Transfer-Encoding for any
TE other than the identity. If the proxy really did use a compression
or chunked transfer encoding, then ignoring this on the client side
(and prepending the encoded 2xx response body to the server-to-client
tunneled application data) would quite clearly be wrong.

It also seems that some clients send the first flight of tunneled
application data in a CONNECT request body. While historically the
semantics of CONNECT request and 2xx response bodies have not been
defined, it is worth pointing out that [it appears, so I'm told; see
below] some clients and some proxies rely on CONNECT request and 2xx
response bodies bearing the first flight of tunneled application data,
and if so, then the RFC should mention it. I'm not sure how much
evidence we can demand for such behaviors, but the RFC demands behavior
that implies the intent described in this erratum and gives no evidence
to support the need for such behavior, therefore it seems much better
to describe the previously-implied intent explicitly and continue with
a little-or-no-evidence approach that should nonetheless yield the most
interoperability.

Finally, I asked for clarification on the HTTPbis list, and the answers
I received indicate that the intent may have been as described in
these notes.

See https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0260.html
and follow-ups.
--VERIFIER NOTES--
This is a change request, not an errata report. Such changes can be proposed in the working group's issue tracker, here:
https://github.com/httpwg/http11bis/issues

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

Reported By: Jeffrey Yasskin
Date Reported: 2018-03-24
Rejected by: Francesca Palombini
Date Rejected: 2021-08-23

Section 8.1 says:

8.1.1.  Procedure

   HTTP method registrations MUST include the following fields:

   o  Method Name (see Section 4)

   o  Safe ("yes" or "no", see Section 4.2.1)

   o  Idempotent ("yes" or "no", see Section 4.2.2)

   o  Pointer to specification text

   Values to be added to this namespace require IETF Review (see
   [RFC5226], Section 4.1).

…

8.1.3.  Registrations

   The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
   populated with the registrations below:

   +---------+------+------------+---------------+
   | Method  | Safe | Idempotent | Reference     |
   +---------+------+------------+---------------+
   | CONNECT | no   | no         | Section 4.3.6 |
   | DELETE  | no   | yes        | Section 4.3.5 |
   | GET     | yes  | yes        | Section 4.3.1 |
   | HEAD    | yes  | yes        | Section 4.3.2 |
   | OPTIONS | yes  | yes        | Section 4.3.7 |
   | POST    | no   | no         | Section 4.3.3 |
   | PUT     | no   | yes        | Section 4.3.4 |
   | TRACE   | yes  | yes        | Section 4.3.8 |
   +---------+------+------------+---------------+

It should say:

8.1.1.  Procedure

   HTTP method registrations MUST include the following fields:

   o  Method Name (see Section 4)

   o  Safe ("yes" or "no", see Section 4.2.1)

   o  Idempotent ("yes" or "no", see Section 4.2.2)

   o  Cacheable ("yes" or "no", see Section 4.2.3)

   o  Pointer to specification text

   Values to be added to this namespace require IETF Review (see
   [RFC5226], Section 4.1).

…

8.1.3.  Registrations

   The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
   populated with the registrations below:

   +---------+------+------------+-----------+---------------+
   | Method  | Safe | Idempotent | Cacheable | Reference     |
   +---------+------+------------+-----------+---------------+
   | CONNECT | no   | no         | no        | Section 4.3.6 |
   | DELETE  | no   | yes        | no        | Section 4.3.5 |
   | GET     | yes  | yes        | yes       | Section 4.3.1 |
   | HEAD    | yes  | yes        | yes       | Section 4.3.2 |
   | OPTIONS | yes  | yes        | no        | Section 4.3.7 |
   | POST    | no   | no         | yes       | Section 4.3.3 |
   | PUT     | no   | yes        | no        | Section 4.3.4 |
   | TRACE   | yes  | yes        | no        | Section 4.3.8 |
   +---------+------+------------+-----------+---------------+

Notes:

HTTP Methods have 3 boolean properties, all of which 8.1.2 says a registration needs to define, but only 2 of them were included in the registry.
--VERIFIER NOTES--
As discussed during work on the HTTP core documents:
> "Cacheable" is not a boolean property of the method, but rather a capability inherent in the system in which one aspect is the method semantics.
See https://github.com/httpwg/http-core/issues/54 for detailed discussion.

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

Reported By: Magnar Ovedal Myrtveit
Date Reported: 2018-08-02
Rejected by: Alexey Melnikov
Date Rejected: 2018-09-04

Section 7.1.1.1 says:

Recipients of a timestamp value in rfc850-date format, which uses a
two-digit year, MUST interpret a timestamp that appears to be more
than 50 years in the future as representing the most recent year in
the past that had the same last two digits.

It should say:

Recipients of a timestamp value in rfc850-date format, which uses a
two-digit year, MUST interpret a timestamp that appears to be more
than 200 years in the future as representing the most recent date in
the past that also matches the timestamp.

Notes:

The combination of day-of-the-week, day-of-the-month, month, and the two last digits of the year repeats every 400 years. For example, "Friday, 01-Jan-00 00:00:00 GMT" (as formatted by rfc850) happens in the years ...1300, 1700, 2100, 2500, 2900...

With the original text, "Friday, 01-Jan-00 00:00:00 GMT" is interpreted as year 2000, since year 2100 is more than 50 years in the future, and year 2000 is the most recent year in the past with the same last two digits as 2100. However, if it really was year 2000, it should have said "Saturday, 01-Jan-00 00:00:00 GMT". So it would make more sense to interpret it as either year 1700 or year 2100. The corrected text interprets it as year 2100.

"Monday, 01-Jan-00 00:00:00 GMT" happens in years ...1100, 1500, 1900, 2300, 2700..., and is interpreted as year 1900, since 2300 is more than 200 years in the future.
--VERIFIER NOTES--
This changes the original intent of the text, so errata mechanism is not suitable.

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

Reported By: Alan Egerton
Date Reported: 2020-04-29
Rejected by: Francesca Palombini
Date Rejected: 2021-04-29

Section 5.3.2 says:

The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence
that matches the type.  For example,

  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
          text/html;level=2;q=0.4, */*;q=0.5

would cause the following values to be associated:

+-------------------+---------------+
| Media Type        | Quality Value |
+-------------------+---------------+
| text/html;level=1 | 1             |
| text/html         | 0.7           |
| text/plain        | 0.3           |
| image/jpeg        | 0.5           |
| text/html;level=2 | 0.4           |
| text/html;level=3 | 0.7           |
+-------------------+---------------+

It should say:

The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence
that matches the type.  For example,

  Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
          text/plain;format=fixed;q=0.4, */*;q=0.5

would cause the following values to be associated:

+--------------------------+---------------+
| Media Type               | Quality Value |
+--------------------------+---------------+
| text/plain;format=flowed | 1             |
| text/plain               | 0.7           |
| text/html                | 0.3           |
| image/jpeg               | 0.5           |
| text/plain;format=fixed  | 0.4           |
| text/plain;delsp=yes     | 0.7           |
+--------------------------+---------------+

Notes:

The optional "level" parameter of media type text/html was removed by informational RFC 2854 (The 'text/html' Media Type), [section 2](https://tools.ietf.org/html/rfc2854#section-2) of which states:

> Note that [HTML20] included an optional "level" parameter; in
> practice, this parameter was never used and has been removed from
> this specification.

More formally, [the current IANA registration of the text/html media type](https://www.iana.org/assignments/media-types/text/html), which is taken directly from [section 16.1 of the HTML specification](https://html.spec.whatwg.org/multipage/iana.html#text/html), does not include a "level" parameter.

Whilst the example is non-normative, it has given rise to misleading information—e.g. in the [MDN Web Docs glossary definition of "quality values"](https://developer.mozilla.org/en-US/docs/Glossary/quality_values), which states:

> Some syntax, like the one of Accept, allow additional specifiers
> like text/html;level=1. These increase the specificity of the value.
> Their use is extremely rare.
--VERIFIER NOTES--
As discussed in the mailing list:

> While it is theoretically possible for media types to no longer define a
> given parameter, it is not possible for them to limit usage of parameters
> in HTTP. This example is still fine.
>
> Note that this example has already been updated in http-core's Accept

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

Reported By: Peter Sturge
Date Reported: 2020-12-10
Rejected by: Barry Leiba
Date Rejected: 2020-12-15

Section 7.1.2. says:

The field value consists of a single URI-reference.  When it has the
   form of a relative reference ([RFC3986], Section 4.2), the final
   value is computed by resolving it against the effective request URI
   ([RFC3986], Section 5).

   For 201 (Created) responses, the Location value refers to the primary
   resource created by the request.  For 3xx (Redirection) responses,
   the Location value refers to the preferred target resource for
   automatically redirecting the request.

   If the Location value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim"

It should say:

The field value consists of a single URI-reference. Relative forms are not allowed and MUST include the entire redirected URI, even if the base URL part has not changed.

Notes:

Relative URIs in Location redirect headers should not be allowed.
Allowing relative URIs opens up, at best, inconsistent and poor implementations and interpretations, but more importantly it opens serious security holes.
For example, when the redirect emanates from a URL shortening service (e.g. bitly.com), an attacker can 'chain' multiple relative shortened URIs, effectively obfuscating the final and malicious site.
If security tools attempt to 'rebuild and resolve', this will have an impact on performance, and itself can be exploited by attackers by creating a circular redirect (this can of course be done with full URIs as well, but then a security monitoring tool can more easily detect such a scenario).
Yes, one would expect security tools to only redirect to a small maximum count (say 3), but in a Denial-of-Service attack, many of these can render a security monitoring tool impotent to other attacks happening in parallel.
In addition, unless *all* User-Agents (and there are a lot of them out there) interpret the relative URL absolutely consistently, this can lead to incorrect navigation at best, and such inconsistencies can be easily exploited by attackers at worst.
All in all, at a time when the industry is trying to make internet operations safer and more secure, allowing relative URLs does the opposite, and with little to no gain by allowing.
--VERIFIER NOTES--
The text says what the working group intended it to say, and this is not an erratum. What's more, it accurately reflects real-world usage.

The place to discuss changes such as this proposal, to be considered for future updates, is the HTTP working group's mailing list; see <https://datatracker.ietf.org/wg/httpbis/about/>.

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

Reported By: Bjoern Hoehrmann
Date Reported: 2015-01-09
Rejected by: Barry Leiba
Date Rejected: 2015-01-17

Section 4.1 and A. D says:

     method = token

It should say:

     method = <method, see [RFC7230], Section 3.1.1>

Notes:

The HTTP/1.1 RFCs define rules imported across documents using prose rules for all rules except this one. This is an error because RFC7231 does not mean to re-define the production rule.
--VERIFIER NOTES--
This is asking for an editorial change, but the errata system is not the place to record proposals for editorial improvements. There is an issue tracker at <https://github.com/httpwg/http11bis/issues> for keeping issues for a possible future HTTP 1.1 update.

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

Reported By: Alexey Blyshko
Date Reported: 2016-07-06
Rejected by: RFC Editor
Date Rejected: 2017-01-25

Section 5.3.5 says:

   The "Accept-Language" header field can be used by user agents to
   indicate the set of natural languages that are preferred in the
   response.  Language tags are defined in Section 3.1.3.1.

     Accept-Language = 1#( language-range [ weight ] )
     language-range  =
               <language-range, see [RFC4647], Section 2.1>

   Each language-range can be given an associated quality value
   representing an estimate of the user's preference for the languages
   specified by that range, as defined in Section 5.3.1.  For example,

     Accept-Language: da, en-gb;q=0.8, en;q=0.7

   would mean: "I prefer Danish, but will accept British English and
   other types of English".

It should say:

   The "Accept-Language" header field can be used by user agents to
   indicate the set of natural languages that are preferred in the
   response.  Language tags are defined in Section 3.1.3.1.

     Accept-Language = 1#( language-range [ weight ] )
     language-range  =
               <language-range, see [RFC5646], Section 2.1>

   Each language-range can be given an associated quality value
   representing an estimate of the user's preference for the languages
   specified by that range, as defined in Section 5.3.1.  For example,

     Accept-Language: da, en-GB;q=0.8, en;q=0.7

   would mean: "I prefer Danish, but will accept British English and
   other types of English".

Notes:

RFC4647 -> RFC5646
en-gb -> en-GB


--VERIFIER NOTES--
Rejected per Mark Nottingham (chair of HTTPBIS WG):
As far as I can tell, language-range is defined in RFC 4647, not in RFC 5646. So the change as proposed seems to be incorrect. (See BCP 47.)

The other change, from 'en-gb' to 'en-GB', may be seen as a tiny stylistic improvement (because the 'canonical' way to write country codes in language tags is upper case), but is not at all required (because language tags are case-insensitive).

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

Reported By: Michael Osipov
Date Reported: 2020-03-16
Rejected by: Barry Leiba
Date Rejected: 2020-07-10

Section 3.1.1.1 says:

 A parameter value that matches the token production can be
   transmitted either as a token or within a quoted-string.  The quoted
   and unquoted values are equivalent.  For example, the following
   examples are all equivalent, but the first is preferred for
   consistency:

     text/html;charset=utf-8
     text/html;charset=UTF-8
     Text/HTML;Charset="utf-8"
     text/html; charset="utf-8"

It should say:

 A parameter value that matches the token production can be
   transmitted either as a token or within a quoted-string.  The quoted
   and unquoted values are equivalent.  For example, the following
   examples are all equivalent, but the first is preferred for
   consistency:

     text/html;charset=utf-8
     text/html;charset=UTF-8

Notes:

Section 3.1.1.2 defines charset value to be a token. I consider this to be a bad example which might cause confusion. Why should I quote the value if it is defined as token?! You make want to use some other example.
--VERIFIER NOTES--
What's relevant is the ABNF for *parameter*, and that allows both token and quoted-string. So the example is correct.

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

Reported By: jk
Date Reported: 2022-01-10
Rejected by: Francesca Palombini
Date Rejected: 2022-01-11

Section Table of Contents says:

noneed

It should say:

noneed

Notes:

There is no hyper link to section 7.1.1 in Contents.
--VERIFIER NOTES--
Errata reports are for the authoritative versions hosted on rfc-editor.org, which for this document is the plain text version. As such, issues introduced by the "htmlization" process do not qualify. Additionally, the issue with the characters "ed " added in the ToC was reported in an errata already, see https://www.rfc-editor.org/errata/eid4072.

Report New Errata



Advanced Search