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

From: <[email-masked]>
Date: Wed, 12 Feb 2014 10:52:13 +0000

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 12 Feb 2014 10:58:49 +0000

+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

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 13 Feb 2014 01:57:33 +1300

>> 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 standardi…

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?

Amos

---

From: Patrick McManus <[email-masked]>
Date: Wed, 12 Feb 2014 10:14:23 -0500

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 <[email-masked]> 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.
>
>

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

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)

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

>  ie SRV _http._tcp.example.com ==> CNAME example.net
follow it!

If so;
>   What to do when the local LAN proxy is both gateway and reverse-proxy
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.

---

From: <[email-masked]>
Date: Wed, 12 Feb 2014 20:01:55 +0000

Hi Salvatore,

AFAIK, SRV allow you to set the port you want in the record. I don't have the need for coexistence and migration. Can you detail the cases ?

Regards
Emile

-----Message d'origine-----
De : Salvatore Loreto [mailto:[email-masked]] 
Envoyé : mercredi 12 février 2014 11:59
À : STEPHAN Emile IMT/OLN
Cc : HTTP Working Group
Objet : Re: issue 381: Discovery of the support of the HTTP2 protocol: DNS-based Upgrade

+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, <[email-masked]>
 wrote:

> All,
> 
> I create an entry in github to discuss this aspect,  see 
> https://github.com/http2/http2-spec/issues/381 ;
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.