RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Reported (3)

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

Source of RFC: httpbis (app)

Errata ID: 4663

Status: Reported
Type: Technical

Reported By: D. Stussy
Date Reported: 2016-04-12

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.)

Errata ID: 4666

Status: Reported
Type: Technical

Reported By: Vasiliy Faronov
Date Reported: 2016-04-13

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.

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

Errata ID: 4871

Status: Reported
Type: Editorial

Reported By: Martin Thomson
Date Reported: 2016-11-30

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.

Status: Held for Document Update (2)

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

Source of RFC: httpbis (app)

Errata ID: 4535

Status: Held for Document Update
Type: Technical

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

Status: Held for Document Update
Type: Editorial

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.

Status: Rejected (1)

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

Source of RFC: httpbis (app)

Errata ID: 4645

Status: Rejected
Type: Technical

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.

Report New Errata



Search RFCs
Advanced Search
×