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

In case #1, you're correct - there are a lot of ways servers could fail.  Clients will have to endure that and have fallback logic.  While 505 is perhaps the most spec-compliant, since the preamble does announce HTTP/2.0, I don't believe I've ever seen a server actually emit that.  Most of the ones I've tried it on just close the connection without answering.

#2 and #3, if we resolve 496 in the direction of an error code, could send a hard-coded sequence of an empty SETTINGS followed by a GOAWAY with the 1.1-required error code, then close the connection.  If we leave it as an enhancement to status code 505, server #3 could use it, but server #2 has a harder job.  That's another argument for making it an error code rather than a status code.

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: Thursday, August 28, 2014 7:28 AM
To: ietf-http-wg@w3.org
Subject: Re: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface

Martin,

Thank you for the response. I believe we are discussing slightly different variants of my original scenario here, so to be a little clearer assume a HTTP/2 client sending a connection preface over cleartext to each of these server variants:


1)      HTTP/1.1 server with no HTTP/2 knowledge or support. For example, extant server that does not understand how to process the request line presented in the preface.

a.      Would it be correct to say this server is expected to fail in a number of possible ways? (e.g. immediately drop TCP connection, respond with 400, 405 or 505 etc.)

b.      Alternatively, does issue 496 infer the failure should be handled by a HTTP/1.1 505 response?

2)      HTTP/1.1 server with HTTP/2 knowledge but no support. For example, server software updated to accommodate this edge case but not capable of generating a HTTP/2 response.

a.      As 1a

b.      As 1b

3)      HTTP/1.1 and HTTP/2 capable server, unable or unwilling to support a sustained HTTP/2 connection.

a.      Fallback to HTTP/1.1 as described by Martin and issue 496. E.g. a possible sequence would be server responds with connection preface, HEADERS frame with :status = 505, GOAWAY frame with error code HTTP_1.1_REQUIRED and then server closes TCP connection.

The common denominator in all variants is that the server closes the TCP connection. My limited testing against variant 1 servers shows they respond with 400 Bad Request.

It could be reasoned that h2c with prior knowledge is the least resilient method of HTTP/2 connection and clients should expect to fail for a range of possible reasons in either HTTP/1.1 or HTTP/2 protocol format or simply a TCP connection drop. A statement to this effect under section 3.4 may be appropriate.

Regards,
Lucas