- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Tue, 22 Sep 2015 11:08:31 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
> Am 21.09.2015 um 20:23 schrieb Mike Bishop <Michael.Bishop@microsoft.com>: > > I have no issue with defining something at the application layer that becomes a viable alternative to move toward. In the meantime, though, we want a way for applications built on the old/current model to use HTTP/2. Thanks, Mike. My feelings exactly. We want sites to enable HTTP/2. We do not want them to crash and go down in flames, because the existing HTTP/1 config was not suitable. We'd like predictable (or at least defined) behaviour of clients when running into whatever the server sends back in such scenarios. In order to completely avoid renegotiations on HTTP/2 (and I think we all agree on that), one approach would be to force the client back to HTTP/1.1 using another (new or open) connection. The response should indicate the realm where this restriction applies. Note that servers may be unable to trigger client certs on connection setup. This often happens on the first request, triggering a renegotiation. Often specific TLS parameters only apply to special locations on a server (in existing configurations - I do not say that this is a good approach). This may be done by extending the 421 response with additional headers to indicate the desired behaviour. It would be good to hear from people on the client side what their thoughts about this are. //Stefan <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Tuesday, 22 September 2015 09:08:55 UTC