- From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
- Date: Tue, 9 Sep 2014 17:02:26 +0000
- To: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
That answers my questions thank you. While I agree that the ACK helps the end point tracking ability, it does complicate the sequence. Following your description I have this sequence in the HTTP/1.1 Upgrade case 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 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? The client has provided settings that the Server implicitly accepted, the server is sending it's connection preface before the client, so the connection preface provides no value other than a redundant SETTINGS that could be sent in a standalone frame if really necessary.
Received on Tuesday, 9 September 2014 17:03:05 UTC