RE: h2 Connection Preface

Following the change made at https://github.com/http2/http2-spec/commit/293e6d041fd9a903ee6dd10b4eee, I can more clearly see how the proposed sequence was mistaken.

> That doesn't work.  If one side changes certain settings, like header table size, the other side needs to know 
> when the change was enacted. 

I think we are talking cross purposes, I was focussed more on Upgrade scenario and the SETTINGS redundancy between HTTP2-Settings and the connection preface. Having done some more reading in the mailing lists (http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0048.html) I agree with the intentions of having both; similar codepaths regardless of entry point, minimal HTTP2-Settings in the HTTP etc.

The argument for similar codepaths would also answer Robby's concern #1.


-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: 09 September 2014 23:32
To: Lucas Pardue
Cc: RUELLAN Herve; Simpson, Robby (GE Energy Management); ietf-http-wg@w3.org
Subject: Re: h2 Connection Preface

On 9 September 2014 10:02, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
> 1. Client sends Upgrade request including SETTINGS in HTTP2-Settings 
> header field 2. Server does not need to ACK (1) (as explained in 
> 3.2.1, however that runs contrary to the MUST described in 6.5) 3. 
> Server sends 101 Switching Protocol 4. Server sends SETTINGS 5. Client 
> ACKS (4) 6. Client sends preface including SETTINGS 7. Server ACKS (6) 
> 8. Server provides response to request 1

I sometimes worry that people intentionally misread the spec to make a point.  Do you really expect the above to work with steps 5 and 6 as shown?

> My Proposition: If we can bend the rules to remove an ACK in the Upgrade sequence, can we also remove the requirement for a client preface?

That doesn't work.  If one side changes certain settings, like header table size, the other side needs to know when the change was enacted.

Received on Wednesday, 10 September 2014 10:32:51 UTC