RE: Feedback on Fallback

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:ilari.liusvaara@elisanet.fi] 
Sent: Monday, September 22, 2014 1:09 PM
To: Mike Bishop
Cc: HTTP Working Group
Subject: Re: Feedback on Fallback

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

Received on Monday, 22 September 2014 22:41:41 UTC