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

From: Lucas Pardue <[email-masked]>
Date: Wed, 27 Aug 2014 17:29:20 +0000

Hello,

I am looking for clarification on the expected behaviour in the scenario where a HTTP/2 client incorrect attempts to establish a HTTP/2 connection over cleartext TCP with a HTTP/1.1 server or intermediary. In this scenario, the client's prior knowledge is incorrect and a connection preface is sent as the first interaction after TCP connection.

The specification states "The client connection preface is selected so that a large proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do not attempt to process further frames.", however I am unclear on what Response should be issued to the client my scenario above. There appears to be fair arguments for returning either 400, 405 or 505 depending upon the implementation parsing of the Request line.

I understand the connection preface has been crafted in order to provide robust handling of several use cases; such that a range of response codes may be valid dependent upon situation, however may it be useful to expand the paragraph in Section 3.5 to capture this succinctly?

Regards,
Lucas

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Aug 2014 11:34:28 -0700

On 27 August 2014 10:29, Lucas Pardue <[email-masked]> wrote:
> I understand the connection preface has been crafted in order to provide
> robust handling of several use cases; such that a range of response codes
> may be valid dependent upon situation, however may it be useful to expand
> the paragraph in Section 3.5 to capture this succinctly?

Firstly, this is only an issue with cleartext.  ALPN is hard to get
wrong, and that's required when you use TLS.

The preface is crafted to ensure that servers drop the connection, or
at least fail spectacularly, rather than break in subtle ways.  If you
are building a server with code that has specific knowledge of HTTP/2,
it's probably better to do a little more work to send the connection
preface yourself and then presumably immediately send whatever we do
to resolve https://github.com/http2/http2-spec/issues/496 [fallback to
HTTP/1.1]

Or, you could choose to fail spectacularly and hopefully trigger some
fallback logic.