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?

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.


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 14:10:54 UTC