RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (4)

RFC 9110, "HTTP Semantics", June 2022

Source of RFC: httpbis (art)

Errata ID: 7107
Status: Reported
Type: Technical
Publication Format(s) : HTML

Reported By: James Synge
Date Reported: 2022-08-31

Section 6.5.1 says:

For example, the chunked transfer coding in HTTP/1.1
allows a trailer section to be sent after the content
(Section 7.1.2 of [HTTP/1.1]).

It should say:

For example, the chunked transfer coding in HTTP/1.1
allows a trailer section to be sent after the content
(Section ?.?.? of [HTTP/1.1]).

Notes:

Section 7.1.2 does not exist. It isn't clear to me which section is the intended target of the reference.

Errata ID: 7109
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Gary Wilson Jr.
Date Reported: 2022-08-31

Section 15.4.9 says:

   The 308 (Permanent Redirect) status code indicates that the target
   resource has been assigned a new permanent URI and any future
   references to this resource ought to use one of the enclosed URIs.

It should say:

   The 308 (Permanent Redirect) status code indicates that the target
   resource has been assigned a new permanent URI and any future
   references to this resource ought to use one of the enclosed URIs.
   The user agent MUST NOT change the request method if it performs
   an automatic redirection to that URI.

and/or add note as is present in RFC 7538, e.g.:

      Note: This status code is similar to 301 (Moved Permanently)
      (Section 15.4.2), except that it does not allow changing
      the request method from POST to GET.

Notes:

The current text in this section for 308 Permanent Redirect does not include any mention of the user agent not changing the request method. I am suggesting that similar wording be used as in 15.4.8. 307 Temporary Redirect and/or a note added similar to the one present in RFC 7538 but excluded from this section's current text. Whichever is chosen, it would be good to make the wording/notes consistent across both the 307 and 308 status code sections.

Errata ID: 7105
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Tomoyuki Sahara
Date Reported: 2022-08-26

Section B.1. says:

B.1.  Changes from RFC 2818

   None.

It should say:

B.1.  Changes from RFC 2818

   The use of CN-ID has been deprecated.

Notes:

In RFC2818:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used.

CN-ID may be used (when a subjectAltName of type dNSName is not present).

In RFC9110:

A reference identity of type CN-ID MUST NOT be used by clients.

CN-ID is not used at all. It is a change from RFC2818.

Errata ID: 7138
Status: Reported
Type: Technical
Publication Format(s) : HTML

Reported By: Yousouf Taghzouti
Date Reported: 2022-09-23

Section 12.5.1 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/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:

Table 5: 

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/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:

Table 5: 

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/html;level=3	             0.3

Notes:

To illustrate how the media type quality factor associated with a given type is determined, the following example is given:

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

The last row of the result table (table 5) presenting the values to be associated cannot be deduced (MediaType: text/html;level=3, Quality Value: 0.7), since only "text/*;q=0.3" and "*/*;q=0.5" are possible values and as explained in the RFC "text/*;q=0.3" should take precedence.

In section 5.3.2 of RFC7231, a similar example is given, where the last row of the table is correct (text/html;level=3 | 0.7) since in that example the accept header contains (text/html;q=0.7).

Report New Errata



Advanced Search