- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Tue, 14 Jul 2015 16:37:09 +0000
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Amos Jeffries <squid3@treenet.co.nz>
- CC: Erik Nygren <erik@nygren.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
IIS/http.sys does this as well. While requests in absolute form are supported, in the event that two different apps have registered listeners for the http://example.com:80/path and https://example.com:443/path resources, a connection on port 443 requesting http://example.com/path gets routed to the second application. That hasn't changed in our HTTP/2 implementation. Frankly, my inclination would be to 503 instead -- *neither* app has registered to serve http://example.com/path over port 443. But that's the legacy we have.... -----Original Message----- From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] Sent: Monday, July 13, 2015 3:28 AM To: Amos Jeffries Cc: Erik Nygren; ietf-http-wg@w3.org Group Subject: Re: http/1 opportunistic encryption On Mon, Jul 13, 2015 at 10:07:01PM +1200, Amos Jeffries wrote: > > If teh server is compliant with HTTP/1.1 it is expected to accept > absolute-URI not just relative-URI. > > My understanding was that :scheme was supposed to be translated into > absolute-URI for the HTTP/1 server when the scheme does not match the > transport protocol used to the server. If it does match then > relative-URI was the right thing to do. > > Whether reality matches that spec behaviour though is a good question. Well, I have seen a server that when contacted over port 443 and then queried for http://example.org/ (using absolute-URI form) would interpret it as query for https://example.org/, and return different data from intended (expected site front page, got some test page with 200 status). It was running Apache with PHP (yuck) using FastCGI. -Ilari
Received on Tuesday, 14 July 2015 16:37:39 UTC