RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (1)

RFC 7540, "Hypertext Transfer Protocol Version 2 (HTTP/2)", May 2015

Note: This RFC has been obsoleted by RFC 9113

Note: This RFC has been updated by RFC 8740

Source of RFC: httpbis (wit)

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

Reported By: Nikolai Malykh
Date Reported: 2017-06-07
Verifier Name: Alexey Melnikov
Date Verified: 2017-06-19

Section 3.5 says:

   That is, the connection preface starts with the string "PRI *
   HTTP/2.0\r\n\r\nSM\r\n\r\n"). 
                              ^ 

It should say:

   That is, the connection preface starts with the string "PRI *
   HTTP/2.0\r\n\r\nSM\r\n\r\n".  

Notes:

Typo

Status: Held for Document Update (5)

RFC 7540, "Hypertext Transfer Protocol Version 2 (HTTP/2)", May 2015

Note: This RFC has been obsoleted by RFC 9113

Note: This RFC has been updated by RFC 8740

Source of RFC: httpbis (wit)

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

Reported By: Erik Schnell
Date Reported: 2015-11-17
Held for Document Update by: Barry Leiba
Date Held: 2015-11-19

Section 5.1 says:

(content of Figure 2)

It should say:

(see notes, below)

Notes:

Section 5.1 Figure 2 is unclear about what stream is being depicted when PUSH_PROMISE is used. The figure shows a transition from /idle/ to /reserved (local)/ on a PUSH_PROMISE receive, but Section 6.6 only allows PUSH_PROMISE to be sent on a stream that is in /open/ or /half-closed (remote)/ state. But these are talking about different streams.

A note should be added to figure 2 in section 5.1 clarifying that where a PUSH_PROMISE is sent or received, the state diagram is for the promised stream, not the original stream.

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

Reported By: Vasiliy Faronov
Date Reported: 2016-04-13
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Section 9.1.2 says:

   A 421 response is cacheable by default, i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

It should say:

   [paragraph removed]

Notes:

The HTTP cache key (RFC 7234 Section 2) is based on the request URI, not on properties of the connection. Therefore, if a client were to cache a 421 response, it would then use this cached 421 to satisfy further requests to the same URI, before it has a chance to connect to an authoritative server.

Mark Nottingham: As discussed on list, I think the best we can do here is to note that in many cases, it'd be desireable to mark this as explicitly uncacheable.

With this paragraph removed, a 421 response is not cacheable by default, per RFC 7231 Section 6.1.

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

Reported By: Mike Bishop
Date Reported: 2020-10-19
Held for Document Update by: Barry Leiba
Date Held: 2020-10-27

Section 5.1 says:

      Receiving any frame other than HEADERS or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.

...and similar throughout the section

It should say:

      Receiving any frame defined in this document other than HEADERS
      or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.  Frames of unknown types are ignored.

Notes:

Discovered via Chrome's GREASE experiment and discussed on-list, but never filed that I can find. The HTTP/2 RFC mandates tolerance of any unknown frame type, but also mandates rejection of frames which are not the few listed. The conservative solution in current deployments is, of course, to restrict sending extension frame types to open (and half-closed (remote)) streams. The text which should have been in the document to begin with, however, is that only frame types defined in the HTTP/2 specification were to be impacted by that restriction.

This is already stated in section 5.1:

In the absence of more specific guidance elsewhere in this document,
implementations SHOULD treat the receipt of a frame that is not
expressly permitted in the description of a state as a connection
error (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can
be sent and received in any stream state. Frames of unknown types
are ignored.

However, it's unclear whether the "any frame other than" language is to be construed as "more specific guidance."

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

Reported By: Kazu Yamamoto
Date Reported: 2016-06-27
Held for Document Update by: Alexey Melnikov
Date Held: 2016-08-11

Section 8.2.1 says:

Pushed responses are always associated with an explicit request from
the client.  The PUSH_PROMISE frames sent by the server are sent on
that explicit request's stream. 

It should say:

Promised requests are always associated with an explicit request from
the client.  The PUSH_PROMISE frames sent by the server are sent on
that explicit request's stream. 

Notes:

This section talks about promised requests, not pushed responses.

Alexey:
As per HTTPBIS WG discussion, this is correct in the original, but clearer in the proposed text.

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

Reported By: Martin Thomson
Date Reported: 2017-02-07
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Throughout the document, when it says:


Notes:

It's unclear from the text whether PRIORITY frames affect stream states (as shown in the state machine in Section 5.1). The original intent was that prioritization of streams was independent of the mechanics of opening and closing streams, but this was not consistently captured.

Two small additions to the document would help considerably.

In Section 5.3 (Stream Priority) add a new paragraph:

> The information that an endpoint maintains for stream priority is separate from other state. Importantly, this includes stream states (Section 5.1). A stream in any state can have its priority changed with a PRIORITY frame. The state of a stream is not changed as a result of changing its priority. The number of streams for which state is remembered is at the discretion of an endpoint, see Section 5.3.4 for details.

In Section 6.4 (PRIORITY) a new sentence at the end of the first paragraph:

> Sending or receiving a PRIORITY frame does not affect the state of any stream (Section 5.1), only the priority of streams is altered.

Status: Rejected (4)

RFC 7540, "Hypertext Transfer Protocol Version 2 (HTTP/2)", May 2015

Note: This RFC has been obsoleted by RFC 9113

Note: This RFC has been updated by RFC 8740

Source of RFC: httpbis (wit)

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

Reported By: Jessie Liu
Date Reported: 2016-03-29
Rejected by: Barry Leiba
Date Rejected: 2016-03-29

Section 5.1 says:

idle:
      All streams start in the "idle" state.

      The following transitions are valid from this state:

      *  Sending or receiving a HEADERS frame causes the stream to
         become "open".  The stream identifier is selected as described
         in Section 5.1.1.  The same HEADERS frame can also cause a
         stream to immediately become "half-closed".

      *  Sending a PUSH_PROMISE frame on another stream reserves the
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (local)".

      *  Receiving a PUSH_PROMISE frame on another stream reserves an
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (remote)".

      *  Note that the PUSH_PROMISE frame is not sent on the idle stream
         but references the newly reserved stream in the Promised Stream
         ID field.

      Receiving any frame other than HEADERS or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.

It should say:

idle:
      All streams start in the "idle" state.

      The following transitions are valid from this state:

      *  Sending or receiving a HEADERS frame causes the stream to
         become "open".  The stream identifier is selected as described
         in Section 5.1.1.  The same HEADERS frame can also cause a
         stream to immediately become "half-closed".

      *  Sending a PUSH_PROMISE frame on another stream reserves the
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (local)".

      *  Receiving a PUSH_PROMISE frame on another stream reserves an
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (remote)".

      *  Note that the PUSH_PROMISE frame is not sent on the idle stream
         but references the newly reserved stream in the Promised Stream
         ID field.

      Receiving any frame other than HEADERS, PUSH_PROMISE or 
      PRIORITY on a stream in this state MUST be treated as a 
      connection error (Section 5.4.1) of type PROTOCOL_ERROR.

Notes:

According to the description above and the state transformation in Figure 2, a stream in the 'idle' state could receive a PUSH_PROMISE frame.

While in the last statement of Original Text, receiving a PUSH_PROMISE on a stream in 'idle' state is a connection error.

Please fix this inconsistency problem.
--VERIFIER NOTES--
This is a duplicate of errata report #4535.

The report is incorrect: the text says "another stream" and has a note that explains this. The confusion that obviously exists should be considered in a future revision of the document.

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

Reported By: D. Stussy
Date Reported: 2016-04-12
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Section 8 omits says:

[Note:  RFC 3875, section 4.1.16, defines the protocol version as:

HTTP-Version = "HTTP" "/" 1*digit "." 1*digit

Nothing in RFC 7540 redefines this.]

It should say:

Add paragraph at end of section 8 (before 8.1) - Clarification:

HTTP/2 preserves the format of the SERVER_PROTOCOL CGI variable,
both in the CGI interface and for any server logging purposes.  Where
a version string is necessary, it is "HTTP/2.0" as defined by RFC 3875.

Notes:

Compatibility is required with a prior published RFC, or a specific change superseding the prior RFC need be explicitly stated. This RFC states in its abstract:

"This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged"

RFC 7540, section 3.5's connection preface string containing "HTTP/2.0" implies that the RFC authors should have forseen this issue, and added a paragraph to section 8 to explicitly state no change in the CGI interface variable SERVER_PROTOCOL was desired. At least one implementation is using a version string of "HTTP/2", not "HTTP/2.0", because of how it is referred in this RFC. ("nghttp2.org" has incorrectly implemented this in its library routines.)
--VERIFIER NOTES--
Mark Nottingham: As discussed on HTTPBIS mailing list, this isn't an issue for the HTTP specification.

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

Reported By: Vasiliy Faronov
Date Reported: 2018-02-01
Rejected by: Alexey Melnikov
Date Rejected: 2018-09-04

Section 3.2.1 says:

     HTTP2-Settings    = token68

It should say:

     HTTP2-Settings    = [ token68 ]

Notes:

An initial SETTINGS frame is explicitly allowed by Section 3.5 to be empty. The payload of an empty SETTINGS frame is an empty sequence of octets, whose base64url encoding is an empty string. Thus, the HTTP2-Settings header field ought to permit an empty string as value. But the ABNF for "token68" does not match an empty string.
--VERIFIER NOTES--
Martin Thomson wrote:

The observation is correct. However, I'm not sure that this is the
solution I would choose. I'm not sure, but I think that an empty
header field would cause problems. Maybe the right conclusion to draw
here is that you have to include at least one setting if you use this
header field.

Alexey:

Agreement in the WG to reject the erratum as proposed, but a better fix might be proposed separately.

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

Reported By: Martin Thomson
Date Reported: 2016-11-30
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Section 5.3.4 says:

For example, assume streams A and B share a parent, and streams C
and D both depend on stream A. Prior to the removal of stream A,
if streams A and D are unable to proceed, then stream C receives
all the resources dedicated to stream A. If stream A is removed
from the tree, the weight of stream A is divided between streams
C and D. If stream D is still unable to proceed, this results in
stream C receiving a reduced proportion of resources. For equal
starting weights, C receives one third, rather than one half, of
available resources.

It should say:

For example, assume streams A and B share a parent, and streams C
and D both depend on stream A. When A is complete, streams C and
D receive all the resources that would be allocated to stream
A. If stream D is unable to proceed, stream C shares resources
with stream B. Assuming equal starting weights on all streams,
this means that streams B and C receive an equal share.  However,
if stream A is removed from the tree, the weight of stream A is
divided between streams C and D. With stream A removed and stream
D unable to proceed, stream C receives a reduced proportion of
resources. For equal starting weights, C receives one third,
rather than one half, of available resources.

Notes:

The example was incorrect. Dependent streams do not receive resources if their parent is blocked; they only receive resources once the parent is complete.

Note that I didn't correct the common misunderstanding regarding the third here. That might be further improved by doing the math. That is:

Before removal: A=N (C=N, D=N), B=N;
After removal: B=N, C=N/2, D=N/2;
Therefore viable streams are B=N and C=N/2 meaning a total pool of 3N/2. The resource proportion allocated to C is therefore (N/2)/(3N/2)=1/3.

But that would probably need an entire section for the example, rather than a single paragraph.
--VERIFIER NOTES--
See HTTPBIS mailing list discussion.

Report New Errata



Advanced Search