RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Held for Document Update (4)

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

Status: Held for Document Update
Type: Technical

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

Errata ID: 4925

Status: Held for Document Update
Type: Editorial

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 (3)

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.

Errata ID: 4663

Status: Rejected
Type: Technical

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

Status: Rejected
Type: Editorial

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



Search RFCs
Advanced Search
×