Re: h2 Connection Preface

On 9/9/14, 12:14 PM, "RUELLAN Herve" <Herve.Ruellan@crf.canon.fr> wrote:


>Some answer below.
>
>>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.

Then it sounds like 6.5.3 needs some re-wording and that would resolve my
2nd concern.  When I see "no other frame processing" and "MUST immediately
emit" I think that no other frames are sent until the ACK is sent and that
essentially everything stops when a SETTINGS frame is received.  And what
you are saying is that the server MUST send its SETTINGS frame prior to
sending an ACK for the client's SETTINGS frame.

A piggyback ACK, if possible, would help here.

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

OK.  So the "configurations" in this case are the various "starting"
mechanisms (i.e., HTTP Upgrade, TLS, Prior Knowledge), specifically HTTP
Upgrade.  Perhaps "some configurations" should be changed to state the
HTTP Upgrade starting mechanism specifically.

Received on Tuesday, 9 September 2014 18:44:31 UTC