Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 3 jan 2015, at 22:53, Mark Andrews <marka@xxxxxxx> wrote:
> 
> I suspect in
> most cases there would be a single SRV record pointing to the hosting
> service.  There is only a single CNAME record pointing to the hosting
> service today.

Yes, except in the case for the bare domain name which there can not be any CNAME records for. For that you might have a "lame" A/AAAA record pair, which references an HTTP server that only gives back 301 to whatever URL you are to use -- where the CNAME exists.

I.e. I want to replace:

1 A lookup for domain
2 AAAA lookup for domain
3 Open HTTP connection to whatever target there was for A or AAAA lookup for domain
4 Get 301 back
5 A lookup for domain in the result of the 301
6 AAAA lookup for domain in the result of the 301
7 Get back CNAME from either 5 or 6
8 A lookup for domain in the result of the CNAME lookup
9 AAAA lookup for domain in the result of the CNAME lookup
10 Open HTTP connection to whatever target there was for A or AAAA lookup for domain

With:

1 URI lookup for domain
2 A lookup for domain in target for URI
3 AAAA lookup for domain in target for URI
4 Open HTTP connection to whatever target there was for A or AAAA lookup for domain

I.e. with the URI lookup you can resolve both the issue with lack of CNAME as zone apex and the initial 301 to whatever the apex of the web site is.

Or similar shortening of the number of roundtrips in DNS or HTTP with SRV (one can argue whether you get rid of the 301 with SRV, or the CNAME or both).

Today I see both 301 redirect and CNAME chain(s) when opening HTTP connections. Lots of them.

   Patrik

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]