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

From: Lucas Pardue <[email-masked]>
Date: Thu, 28 Aug 2014 14:27:44 +0000

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Aug 2014 14:39:08 +0000

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:[email-masked]]
Sent: Thursday, August 28, 2014 7:28 AM
To: [email-masked]
Subject: Re: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface

Martin,

a.      As 1a

b.      As 1b

Regards,
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 28 Aug 2014 15:56:09 +0000

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:[email-masked]]
Sent: 28 August 2014 15:39
To: Lucas Pardue; [email-masked]
Subject: RE: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface

From: Lucas Pardue [mailto:[email-masked]]
Sent: Thursday, August 28, 2014 7:28 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface

Martin,

a.       As 1a

b.      As 1b

Regards,
Lucas

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Aug 2014 11:39:51 -0700

On 28 August 2014 08:56, Lucas Pardue <[email-masked]> wrote:
> However, hypothetically it may contain special handling for the request line
> and could correctly issue a 505 via HTTP/1.1, with enhancement.

I'll point out that there's nothing correct about the preface we send,
so any behaviour that is immediately obvious as a failure, like
dropping the connection, or something like 505, is OK here.  The key
is to avoid misleading the client into thinking that its assumption of
HTTP/2 support was correct.  Generating a valid HTTP/2 GOAWAY, with
all the lead-in, is probably the best way to avoid this, assuming that
the client understands the code we choose.  (Mike, that's an argument
for resolving this issue now rather than later; I'll follow up on
that.)

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Aug 2014 18:48:33 +0000

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:[email-masked]]
Sent: Thursday, August 28, 2014 8:56 AM
To: Mike Bishop; [email-masked]
Subject: RE: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface

Lucas

From: Mike Bishop [mailto:[email-masked]]
Sent: 28 August 2014 15:39
To: Lucas Pardue; [email-masked]<mailto:[email-masked]>
Subject: RE: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface

Martin,

a.      As 1a

b.      As 1b

Regards,
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 29 Aug 2014 10:51:27 +0000

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:[email-masked]]
Sent: 28 August 2014 19:49
To: Lucas Pardue; [email-masked]
Subject: RE: Clarification on HTTP/1.1 Server Response to HTTP/2 Client Connection Preface