- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 31 Mar 2016 08:54:33 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP WG <ietf-http-wg@w3.org>, Mike Bishop <Michael.Bishop@microsoft.com>
On 2016-03-31 02:42, Martin Thomson wrote: > Thanks Julian, > > You can find this all on > https://github.com/httpwg/http-extensions/pull/164. Feel free to Thanks, and... > merge if you are happy and we can continue with the remaining changes. ...done. > ... >> 8.4. Confusion Regarding Request Scheme >> This section looks a bit unstructured. Paragraph 3 seems to restate what >> Paragraph 1 already says. >> >> Paragraph 2 IMHO needs to be clearer: it refers to the protocol used to >> perform the opp-sec-ed request, not the original one, right? FWIW, I still >> think that the reasoning for this is weak (an HTTP/2 server stack might >> suffer from the same problem), and thus should either be relaxed, or better >> explained. > > I've restructured this and explained the distinction between discovery > and use a little better, but I'm not going to change the fundamentals > here. We've gone over that point a fair number of times already and I > thought that we had reach some sort of pseudo-acceptable (if weak) > compromise position on it. > ... With the latest changes, this now reads: "Some HTTP/1.1 implementations use ambient signals to determine if a request is for an https resource. For example, implementations might look for TLS on the stack or a port number of 443. This is necessary in many cases because the most common form of an HTTP/1.1 request does not carry an explicit indication of the URI scheme. An implementation that is serving an opportunistically secured request SHOULD suppress these signals for http resources. HTTP/1.1 MUST NOT be used to serve opportunistically secured requests. HTTP/1.1 can be used to discover an opportunistically secured alternative service." The problem remains that this is not really specific to HTTP/1.1; for instance, code running inside Apache over HTTP/2 may have exactly the same problem (Stefan E. to confirm); so it's more a matter of HTTP server internal APIs, not the on-the-wire protocol. I believe this needs to be rephrased to better explain the actual problem; and I also remain unconvinced that the conclusion wrt HTTP/1.1 makes sense. Best regards, Julian
Received on Thursday, 31 March 2016 06:55:09 UTC