- From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
- Date: Thu, 28 Aug 2014 14:27:44 +0000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A9EBCBB@BGB01XUD1012.national.core.bbc.co.uk>
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
Received on Thursday, 28 August 2014 14:28:15 UTC