W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

RE: h2 Connection Preface

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 9 Sep 2014 16:14:00 +0000
To: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E5333AF070@ADELE.crf.canon.fr>
Some answer below.

> -----Original Message-----
> From: Simpson, Robby (GE Energy Management)
> [mailto:robby.simpson@ge.com]
> Sent: mardi 9 septembre 2014 16:10
> To: ietf-http-wg@w3.org
> Subject: h2 Connection Preface
> 
> I have 4 concerns with the text for connection preface:
> 
> Concern 1)
> >From http://tools.ietf.org/html/draft-ietf-httpbis-http2-14, section 3.5:
> 
> >   The client connection preface starts with a sequence of 24 octets,
> >   which in hex notation are:
> >
> >     0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
> >
> >   (the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n").  This sequence is
> >   followed by a SETTINGS frame (Section 6.5).  The SETTINGS frame MAY
> >   be empty.
> 
> 
> Why does the client need to send an empty SETTINGS frame if it is OK with
> the defaults?  Ditto for the server?
> 
> 
> Concern 2)
> >From http://tools.ietf.org/html/draft-ietf-httpbis-http2-14, section 3.5:
> 
> 
> >   The server connection preface consists of a potentially empty
> >   SETTINGS frame (Section 6.5) that MUST be the first frame the server
> >   sends in the HTTP/2 connection.
> 
> 
> But we also have in section 6.5.3:
> 
> >   The values in the SETTINGS frame MUST be processed in the order they
> >   appear, with no other frame processing between values.  Unsupported
> >   parameters MUST be ignored.  Once all values have been processed, the
> >   recipient MUST immediately emit a SETTINGS frame with the ACK flag
> >   set.
> 
> 
> So which is it?  Does the client send the SETTINGS frame and the server
> ACK and then send a SETTINGS frame?  Or must the server send its SETTINGS
> before acknowledging those of the client?

3.5 rules here: the server sends its SETTINGS first and then acknowledge those of the client. It is possible for the server to send other frames after its first SETTINGS frame and before acknowledging the SETTINGS frame of the client.

6.5.3 states that when receiving a SETTINGS frame with several parameters (e.g.: SETTINGS_HEADER_TABLE_SIZE + SETTINGS_MAX_CONCURRENT_STREAMS + SETTINGS_INITIAL_WINDOW_SIZE), then all these parameters must be applied atomically and acknowledged in the same SETTINGS frame. It is not possible to apply SETTINGS_HEADER_TABLE_SIZE, to send a few frames, and then to apply SETTINGS_HEADER_TABLE_SIZE.

> 
> Bottom line: I think we need text regarding the acknowledgement of
> SETTINGS during the connection preface.
> 
> Concern 3)
> 
> >From http://tools.ietf.org/html/draft-ietf-httpbis-http2-14, section 3.5:
> 
> 
> >   To avoid unnecessary latency, clients are permitted to send
> >   additional frames to the server immediately after sending the client
> >   connection preface, without waiting to receive the server connection
> >   preface.  It is important to note, however, that the server
> >   connection preface SETTINGS frame might include parameters that
> >   necessarily alter how a client is expected to communicate with the
> >   server.  Upon receiving the SETTINGS frame, the client is expected to
> >   honor any parameters established.  In some configurations, it is
> >   possible for the server to transmit SETTINGS before the client,
> >   providing an opportunity to avoid this issue.
> 
> 
> I'd be curious to hear more about "some configurations."  Considering some
> servers may wish to make certain their settings are received prior to any
> additional frames being sent by the client, I believe we need to describe
> how this is possible.

Typically, when starting HTTP/2 through an Upgrade from HTTP/1.1 (3.2), the server sends its settings first, just after the 101 response.

Typically, when starting HTTP/2 with Prior Knowledge (3.4), the client sends its settings first.

> Concern 4) -- This is more of a general issue with the SETTINGS frame.
> 
> >From http://tools.ietf.org/html/draft-ietf-httpbis-http2-14, section 6.5:
> 
> 
> >   ACK (0x1):  Bit 1 being set indicates that this frame acknowledges
> >      receipt and application of the peer's SETTINGS frame.  When this
> >      bit is set, the payload of the SETTINGS frame MUST be empty.
> >      Receipt of a SETTINGS frame with the ACK flag set and a length
> >      field value other than 0 MUST be treated as a connection error
> >      (Section 5.4.1) of type FRAME_SIZE_ERROR.  For more info, see
> >      Settings Synchronization (Section 6.5.3).
> 
> 
> Why is piggybacking of ACKs disallowed?  We could thus save 9 octets,
> particularly during the connection preface.
> 
> 
> 
> Robby Simpson, PhD
> System Architect
> GE
> Digital Energy
> 
> 
Received on Tuesday, 9 September 2014 16:14:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC