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

I think DNS SRV is very promising - especially when used in conjunction
with Alternate-Services to accelerate discovery. I talked about that a bit
in zurich, along with some data we gathered on the topic. I believe it made
the minutes. If not I can resummarize in this thread.

However, the limited experiment we ran in Firefox should not be construed
as deployment experience - it only studied RR reachability, it didn't
actually use that information for any connection management. Also, there
are corner cases to be studied - I think Amos identifies one upthread. I'm
honestly a lot more comfortable with Alternate-Services going into the spec
than SRV. Though I like SRV because it has real advantages over the other
discovery mechanisms.

The http/2 rfc ought to leave room to be compatible with this approach, and
I believe 3.4 already does that. But we should standardize it separately if
that path bears fruit.


On Wed, Feb 12, 2014 at 7:57 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

>
> >>
> >> 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.
>
>

> 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?
>
>
For transition purposes, I generally think you would see a http/1 server on
80 and an http/2 server on some-other-port serving the same content.
Legacy clients would continue to access port 80, while newer ones could go
right to http/2. The client using the SRV information has an advantage as
it would be able to start http/2 without an upgrade or alt-services
indirection and would also be able to avoid sending requests in the clear
to an origin that was setup to do http:// over TLS.

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

by default I would say SRV records should only be used for URLs using the
default port. (which also means explicit :80 does not use them, only
implicit 80). We could also define a srv namespace for non default ports as
a further measure. (i.e. http://www.example.com:81 could lookup the srv for
81._http2tls.www.example.com or somesuch)


>
> 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)?
>

the srv is a route - just like cname is a route and multiple A's are
routes. fallback behavior is simiilarly undefined - but I think I would
consider the security implications of the protocols offered in your
scenario and if they were worse than the default cleartext port 80 route
(unlikely :)) I would revert to the default route.


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


>
> 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?
>
>
>
I think the base proposal is really for how to map origins to alternate-svc
via dns srv. As a sort of acceleration of alt-svc or upgrade. mapping
http/2 for a forward proxy probably does require a small tweak - perhaps
the port number lookup mentioned above gets us there. But I think this is a
good example of why this shouldn't be stuffed in the draft at this point in
time.