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.

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

In variant #2, the server is incapable of responding to the client via HTTP/2, so it shares more in common with #1. However, hypothetically it may contain special handling for the request line and could correctly issue a 505 via HTTP/1.1, with enhancement. Alternatively, view #2 server as having "partial support" for HTTP/2 in so far as it can respond with your suggested sequence but is unable to provide any other HTTP/2 functionality, it then becomes effectively the same as #3.

For a server that understands the preface and is able to respond via HTTP/1.1 or HTTP/2, I presume the preference would be a HTTP/2 response but is that a requirement?

Lucas

From: Mike Bishop [mailto:Michael.Bishop@microsoft.com]
Sent: 28 August 2014 15:39
To: Lucas Pardue; ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>
Subject: 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<mailto: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