[jsr369-experts] Greg Wilkins: questions about HTTP/2 spec

From: Edward Burns <edward.burns_at_oracle.com>
Date: Wed, 11 Feb 2015 11:58:38 -0800

Hello Greg,

I recently read through h2 draft 16 and am in the process of submitting
an editorial change pull request, I've filed issue 715 for this with
pull request 08c4b13 for this. If you could advocate for this to be
accepted I would appreciate it. I have some questions about the spec
for you, some of which may cause another pull request.

Section 3.2 Starting HTTP/2 for "https" URIs


  Once TLS negotiation is complete, both the client and the server MUST
  send a connection preface (Section 3.5).

Is the need for the connection preface unique to h2 or is it also
present for h2c?

4.3. Header Compression and Decompression


   Header blocks MUST be transmitted as a contiguous sequence of frames,
   with no interleaved frames of any other type or from any other

Is this the source of your "HOL blocking is still a problem" assertion?

5.2.1. Flow Control Principles


   2. Flow control is based on window update frames. Receivers
       advertise how many octets they are prepared to receive on a
       stream and for the entire connection. This is a credit-based

What is a credit-based scheme?

5.3.4. Prioritization State Management

  When a stream is removed from the dependency tree, its dependencies
  can be moved to become dependent on the parent of the closed stream.

Is "removed" equivalent to "closed" here?

5.5. Extending HTTP/2


  Note that treating any frame other than DATA frames as flow controlled
  is such a change in semantics, and can only be done through

Was this text added at your request?



   Prioritization information in a HEADERS frame is logically equivalent
   to a separate PRIORITY frame, but inclusion in HEADERS avoids the
   potential for churn in stream prioritization when new streams are

What is meant specifically by churn here?



   A SETTINGS frame with a length other than a multiple of 6 octets MUST
   be treated as a connection error (Section 5.4.1) of type

Why this 6 octet rule?

6.5.2. Defined SETTINGS Parameters


   SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This advisory setting informs a
      peer of the maximum size of header list that the sender is
      prepared to accept, in octets.

It seems to be a layering violation to have HPACK specific parameters
here in this spec, don't you think?

   SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial
      window size (in octets) for stream level flow control. The
      initial value is 2^16-1 (65,535) octets.

Perhaps this should be renamed SETTINGS_INITIAL_STREAM_WINDOW_SIZE?



   There is an inherent race condition between an endpoint starting new
   streams and the remote sending a GOAWAY frame.

Can you please explain this race condition to me?

7. Error Codes

   NO_ERROR (0x0): The associated condition is not as a result of an
      error. For example, a GOAWAY might include this code to indicate
      graceful shutdown of a connection.

Why not make this a "must"? At least it a "should". A "might"? That's
not even defined anywhere.

8.2.1. Push Requests


  The PUSH_PROMISE frames sent by the server are sent on that explicit
  request's stream.

Seems like this should be a MUST, no?


   The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to
   sending any frames that reference the promised responses. This
   avoids a race where clients issue requests prior to receiving any
   PUSH_PROMISE frames.

Why is this not a MUST? Indeed the first text of the next section
indicates this is indeed a MUST.

8.2.2. Push Responses


   Once a client receives a PUSH_PROMISE frame and chooses to accept the
   pushed response, the client SHOULD NOT issue any requests for the
   promised response until after the promised stream has closed.

How does the clint signal that it chooses to accept the pushed response?
By not sending a GOAWAY? If so, that should be stated.

What are your thoughts on these?



| edward.burns_at_oracle.com | office: +1 407 458 0017
| 18 days til DevNexus 2015
| 28 days til JavaLand 2015
| 38 days til CONFESS 2015
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 18 days til DevNexus 2015
| 28 days til JavaLand 2015
| 38 days til CONFESS 2015