RE: Alt-Svc over DNS

I think you’re making up / projecting implementation details.  😉  If the hostname is omitted, then the hostname is the origin hostname – not the particular IP address(es) that hostname currently resolves to and the client can reach.  So if on a subsequent connection the client is able to use a different address family (for whatever reason), it will continue to use the Alt-Svc entry it was provided.

As to the rest, I don’t see a strong need to prohibit “clear,” since it’s valid for an origin to publish that it doesn’t currently have an Alt-Svc record and would like you to flush anything you have cached.  Of course, if you’re handing out entries over HTTP, this is probably a bad plan since any DNS-enabled implementation would dump its records every time it found your DNS entry.  All the Alt-Svc behavior (persist, etc.) is unmodified.

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: Monday, January 22, 2018 7:12 AM
To: Ben Schwartz <bemasc@google.com>
Cc: ietf-http-wg@w3.org
Subject: RE: Alt-Svc over DNS

Hi Ben,

> Interesting.  I think as a server operator, if you want to be able to do this kind of cache purging, you can't use ALTSVC.  DNS is fundamentally not compatible with cache purging.  We could add some text to that effect.

I think that some text would help. Is "clear" perhaps worth prohibiting in the ALTSVC frame?

On a seperate point, you don't explicitly address the discussion of network change in RFC 7838 Section 3.1. This relates to the "persist" flag. With DNS ALTSVC, is the same behaviour inherited?

> I don't think this generates any meaningful change: ALTSVC is scoped to the origin, not to an IP.  If a client is performing A and AAAA queries, then it's a dual-stack client starting happy eyeballs.  The client just does happy eyeballs with these IP addresses, and the connection parameters specified in ALTSVC.

> If you think it's unclear we can add text for it, but it seems pretty straightforward to me.  We could equivalently say that it's as if you got an Alt-Svc that included the origin as the hostname, and then had to do happy eyeballs to connect.

I was thinking aloud in my previous mail. I do understand your response but think it might be missing the original point I was making. Here was my though process:

A pathological server may want to advertise different alternatives based on the IP family, and HTTP Alt-Svc theoretically supports the case - the origin will deliver the Alt-Svc information on the IP that the client is currently connected to. When the host is omitted, the IP of the alternative (and hence its family) is inferred from the connected-to origin. (Or I'm making up implementation detail...)

I don't know if the theoretical case needs addressing explicitly. I do think the sequence of actions in section 4.2 could be tightened up but that could be done in response to feedback from implementers of this spec at a later date.

Regards
Lucas

Received on Sunday, 21 January 2018 23:02:39 UTC