Subject: RE: Feedback on Fallback

From: Mike Bishop <[email-masked]>
Date: Mon, 22 Sep 2014 19:24:48 +0000

Just to recap this suggestion, we're not suggesting that any class of traffic should be bulk-relegated to HTTP/1.1 - we're suggesting the addition of a widely-recognized error code to smooth transitions.  Burning a round-trip isn't ideal, but it's a mitigation strategy for limitations on either the client or the server.  In particular, a later thread (http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1894.html) raised the use of such an error code in a GOAWAY as a good hard-coded response to a client that attempts to connect with prior knowledge and gets it wrong.  A server that's aware of HTTP/2 but doesn't support it can generate an appropriate GOAWAY and close the connection.

I submitted a pull request adding the error code at https://github.com/http2/http2-spec/pull/599 -- are there any comments on this change or is this editor-ready?

From: Mike Bishop
Sent: Thursday, August 14, 2014 3:56 PM
To: HTTP Working Group
Subject: Feedback on Fallback

Going into WGLC, we committed to implementations and taking changes based solely on implementation experience and real-world data.  Based on our experience so far, Microsoft's first piece of WGLC feedback is to replace Mark's Over-Version draft<http://tools.ietf.org/html/draft-nottingham-http-over-version-00> with an error code in the spec.  Our reasoning follows.

As we continue to work on HTTP/2, one item that has come up repeatedly is the need to force clients back to HTTP/1.1 for various reasons.  We've all pushed hard against bulk-relegating any class of HTTP usage into the "They should just use 1.1" bucket, but it's becoming clear that there will occasionally be situations where a server needs a client to fall back.

Some apps we support depend on the ability to emit raw HTTP protocol text.  Others require client certs as a matter of local law and we don't have a way to retrieve the client cert without renegotiation.  Others are strictly situational, features that require adaptation work we haven't gotten to yet.

These assorted situations motivated the Over-Version draft which Mark published after the NYC Interim.  505 was already defined as meaning the server was unable/unwilling to use the current HTTP version to serve the request the client made; Mark's draft added semantics to inform a client what version would be acceptable, if any, so that an intelligent client could transparently retry over the correct HTTP version (be it 1.1 or 3.5).

We've found a couple limitations with this approach:

*         As Jeff pointed out in NYC, returning a 5XX looks bad in server logs.  This isn't actually a server "failure" per se, we just used it because the status code already exists in the 5XX range.  Not a technical issue, but definitely an operational one.  (Jeff noted in NYC that there are other 5XX status codes that Twitter non-standardly recasts in other ranges for this reason.  New 4XX and 3XX codes were proposed as part of this discussion, demonstrating that the concept doesn't bucket well as a status code.)

*         Once the HEADERS frame with :status is sent, we're locked in to that response.  You can't subsequently change the :status to 505.  Some of these situations can occur when the response is partially-generated, which leaves us stuck unless we buffer all responses until they're complete (unacceptable for perf).

*         Because Over-Version is optional, clients are not guaranteed to support it.  An unsupporting client will just retry the same request over HTTP/2 again and never be able to obtain an actual response from the server.  Including a response body with the 505 telling clients to turn off HTTP/2 in their browser is definitely not a direction we want to go in these situations, and I don't expect clients to have a "turn off HTTP/2 for this request only" button.

On the other hand, a new error code doesn't suffer from these issues.  A RST_STREAM can be sent at any point and doesn't necessarily confuse existing heuristics.  A GOAWAY with the same error code provides a clean way for the server to transition a client to HTTP/1.1 entirely, if necessary.  If it's in the base spec, we can be assured that any client will be able to understand it and respond appropriately.

Thus, we think an "HTTP/1.1 Required" error code will be a better option than proceeding with the Over-Version draft.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 22 Sep 2014 23:09:00 +0300

On Mon, Sep 22, 2014 at 07:24:48PM +0000, Mike Bishop wrote:

> Some apps we support depend on the ability to emit raw HTTP protocol
> text. 

Are there any HTTP/1.1 messages that can't be gatewayed into HTTP/2?

I know earlier there were some, but I thought those problems have
been fixed.

> Others require client certs as a matter of local law and we don't
> have a way to retrieve the client cert without renegotiation. 

Renegotiation is dangerous in multiplexed protocols. And even more
dangerous with typical usage of HTTP.

I thought there was proposal for httpauth and TLS extensions to
tackle usage of client certificates in HTTP/2? What's the status
of those?

Also, I think those extensions, along with some other stuff
could be useful in order to implement usable client certificate
authentication (right now, CC is infamous for terrible UX).

-Ilari

---

From: Mike Bishop <[email-masked]>
Date: Mon, 22 Sep 2014 22:41:13 +0000

That specific instance is a question of how tortured a code-path we want to invest in a deprecated feature -- it would entail creating a raw HTTP/1.1 response parser inside an HTTP server, which is... less than ideal.  For client certs, likewise, I agree that there's a lot that TLS *could* do to improve the way it's handled -- but those things don't yet exist, and there needs to be a transition story until they do.

More generally, this error code provides an escape valve and eases gradual deployment of HTTP/2.  A client that supports common cases over HTTP/2 but has some corner cases not-yet-implemented always has the option to choose what protocol it uses to make a given request.  The server can't know whether it's in the corner case until it sees the client request, and doesn't have the same freedom to choose -- unless the protocol provides it.

-----Original Message-----
From: Ilari Liusvaara [mailto:[email-masked]] 
Sent: Monday, September 22, 2014 1:09 PM
To: Mike Bishop
Cc: HTTP Working Group
Subject: Re: Feedback on Fallback

I know earlier there were some, but I thought those problems have been fixed.

> Others require client certs as a matter of local law and we don't have 
> a way to retrieve the client cert without renegotiation.

Renegotiation is dangerous in multiplexed protocols. And even more dangerous with typical usage of HTTP.

I thought there was proposal for httpauth and TLS extensions to tackle usage of client certificates in HTTP/2? What's the status of those?

Also, I think those extensions, along with some other stuff could be useful in order to implement usable client certificate authentication (right now, CC is infamous for terrible UX).

-Ilari