- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Wed, 17 Jun 2015 10:50:45 +0200
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> Am 17.06.2015 um 10:34 schrieb Ilari Liusvaara <ilari.liusvaara@elisanet.fi>: > > On Wed, Jun 17, 2015 at 10:20:31AM +0200, Stefan Eissing wrote: >> >>> Am 17.06.2015 um 05:15 schrieb Mark Nottingham <mnot@mnot.net>: >>> >>>> >>>> On 16 Jun 2015, at 6:32 pm, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: >>>> >>>> Reading (again) https://httpwg.github.io/http-extensions/encryption.html, some questions: >>>> >>>> * If configuring a old-school http/1 only server for this, the Alt-Svc announcement would be: >>>> Alt-Svc: http/1.1=":81" >>>> ? >>> >>> See <https://httpwg.github.io/http-extensions/encryption.html#confusion-regarding-request-scheme>; "HTTP/1.1 MUST NOT be used for opportunistically secured requests." >> >> Thanks for pointing me there. >> >> What is the scenario exactly that clients, knowledgeable of Alt-Svc, >> will confuse htttp: and https: URIs? With an Alt-Svc sitting at the >> endpoint of a TLS connection, no middle box confusion is involved. >> I would also assume that a server announcing such a service knows >> what it's doing (for example using a special port for this service). >> So, 6.4 does not explain to me (and maybe other readers) what the >> MUST NOT is about. > > It is not about the clients being confused. It is about the eventual > server being confused. > > Most servers perform http/https detection on HTTP/1.1 by transport, > so if one has TLS connection, those assume it is https://. And that > can't be overriden by using the authority form, even if it has > explicit protocol, so that can't be used. Well, it's the server that announces the Alt-Svc, so it has to know what it's doing - as with everything else. I agree that it seems unwise to place a service for opportunistic encryption onto port 443. I fail to see why it would be a problem to offer it at another, special port for this transport service. Instead, I see an opportunity for existing servers to support such a configuration without the need to support h2 first. Since for server software, main stream servers are reluctant to bring in h2 into their existing releases - understandably since it impacts their core processing engine. And even if, apart from some very skilled users, most people will have to wait for their OS maintainers to adopt it. That is the reason why I ask: do we need to kill opportunistic encryption for HTTP/1.1 servers in general? <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Wednesday, 17 June 2015 08:51:11 UTC