W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: issue 381: Discovery of the support of the HTTP2 protocol: DNS-based Upgrade

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 13 Feb 2014 01:57:33 +1300
Message-ID: <52FB6FBD.1030503@treenet.co.nz>
To: ietf-http-wg@w3.org
On 12/02/2014 11:58 p.m., Salvatore Loreto wrote:
> +1 x DNS SRV
> but I think it would be great to generalise its usage to discover if a domain support HTTP/1.1 or HTTP/2 or both
> independently if they run on different ports or on the same port.
> /Salvatore
> On Feb 12, 2014, at 12:52 PM, <emile.stephan@orange.com>
>  wrote:
>> All,
>> I create an entry in github to discuss this aspect,  see https://github.com/http2/http2-spec/issues/381 ;
>> HTTP2 is carried over TCP. So when HTTP1 and HTTP2 are not carried on the same TCP port, browsers need a mechanism to discover this port. DNS SRV provides such a mechanism and is already standardized. So I propose to add this discovery mechanism in a new section in section 3.
>> Regards
>> Emile

For what reason would an HTTP origin server be running on a port other
than 80 without having informed clients of the port via means such as URL?

What to do if SRV record states a different port to URL?

What to do if SRV record states specific version using port X but
connecting to it results in 4xx status with Upgrade: or ALPN response
stating other protocol(s)?

What to do if SRV record is CNAME to other domain?
 ie SRV _http._tcp.example.com ==> CNAME example.net

Do we also use SRV to identify local LAN proxy gateway?
If so;
  How will it differ from origin server SRV records?

  What to do when the local LAN proxy is both gateway and reverse-proxy
for local domain name?

Received on Wednesday, 12 February 2014 12:58:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC