RE: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface

I agree, the fallback sequence sent to the client would provide a graceful exit and allow the client to proceed with confidence to HTTP/1.1 immediately.

Client implementations would likely want to trade off the guaranteed round trips of the h2c upgrade path vs. the risks of h2c prior knowledge failure and the cost of failure handling, TCP connection reestablishment etc.  However, that goes beyond the scope of the original issue.

My original question has been answered, thank you for your time.

From: Mike Bishop [mailto:Michael.Bishop@microsoft.com]
Sent: 28 August 2014 19:49
To: Lucas Pardue; ietf-http-wg@w3.org
Subject: RE: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface

No, there's never a requirement that a server support a given protocol.  (Unless it's using TLS, in which case I would hope there's a requirement somewhere that it not negotiate a protocol it won't speak.)  Clients always have to deal with their guess being wrong, or things having changed since they got their information.

For server #2, I was thinking of a hardcoded "If I see this request, I send back these bytes and close the connection."  To me, that's the difference in #3 -- #3 actually knows what it's sending and walks through a "real" HTTP/2 state machine rejecting the connection.  #2 just spits a buffer back at the client as a special case.