5 ms·

Notice that Amos was arguing for a happy-eyeballs approach, which removes the round trip. The issue isn't the wait for an extra round trip, it's making it manda

by Lukasa 12y ago

Notice that Amos was arguing for a happy-eyeballs approach, which removes the round trip. The issue isn't the wait for an extra round trip, it's making it mandatory to wait for an SRV result before using an A result. If the language says "You MUST consult SRV records for _http2._tcp before you use the result of an A lookup", then anything that delays that SRV lookup will delay page resolution. Browsers are strongly disincentivised from making anything slow, so it's just safer not to add the extra delay point. If we specced that, no-one would do it. Better to have what we have now, which is: do SRV if you want.

teddyh 12y ago
The SRV record should normally be cached, so it would not be slow just for existing. What Amos was talking about is the problem of some resolvers not returning an answer at all, not even NXDOMAIN or an empty authoritative answer, due to the fact that he queried for AAAA records and some resolvers are buggy and can’t handle those queries. SRV is irrelevant to this problem, except that using “happy-eyeballs” and requiring A and AAAA has problems. What William Chan (陈智昌) was talking about was where a query for SRV records fail, causing a long timeout. But this is not the normal case; normally you get an answer (perhaps an empty one) immediately. And since this has nothing to do with IPv6 and buggy resolvers, I don’t know why this situation should be considered common enough to optimize for. (Clients which really wanted to mitigate this could certainly detect this case when it happens and keep a blacklist.)
teddyh 12y ago
> […] anything that delays that SRV lookup will delay page resolution. You keep implying that such things will happen. They won’t. There is no reason for an SRV record lookup to delay page resolution any more than an A (or AAAA) record lookup. > If we specced that, no-one would do it. Are you seriously saying that even if the HTTP/2 standard came out and it said “A client MUST lookup an SRV record and use it if one exists, and not use any A or AAAA records before the non-existence of an SRV record can be confirmed.”, that the browser vendors would simply ignore this? If that’s the case, why do we even have a standards process? Why do we even pretend to write RFCs if we can just assume that every implementer will ignore the standard and do whatever they feel like? No, a thing which would be a net win for the Internet in general should go in the standard. RFC writers should not bow to fears of what Google, IBM, or General Motors might or might not do. Or, at least, wait until they make the threat of non-compliance openly.

by Lukasa 12y ago

teddyh 12y ago

The SRV record should normally be cached, so it would not be slow just for existing. What Amos was talking about is the problem of some resolvers not returning an answer at all, not even NXDOMAIN or an empty authoritative answer, due to the fact that he queried for AAAA records and some resolvers are buggy and can’t handle those queries. SRV is irrelevant to this problem, except that using “happy-eyeballs” and requiring A and AAAA has problems. What William Chan (陈智昌) was talking about was where a query for SRV records fail, causing a long timeout. But this is not the normal case; normally you get an answer (perhaps an empty one) immediately. And since this has nothing to do with IPv6 and buggy resolvers, I don’t know why this situation should be considered common enough to optimize for. (Clients which really wanted to mitigate this could certainly detect this case when it happens and keep a blacklist.)

teddyh 12y ago

> […] anything that delays that SRV lookup will delay page resolution. You keep implying that such things will happen. They won’t. There is no reason for an SRV record lookup to delay page resolution any more than an A (or AAAA) record lookup. > If we specced that, no-one would do it. Are you seriously saying that even if the HTTP/2 standard came out and it said “A client MUST lookup an SRV record and use it if one exists, and not use any A or AAAA records before the non-existence of an SRV record can be confirmed.”, that the browser vendors would simply ignore this? If that’s the case, why do we even have a standards process? Why do we even pretend to write RFCs if we can just assume that every implementer will ignore the standard and do whatever they feel like? No, a thing which would be a net win for the Internet in general should go in the standard. RFC writers should not bow to fears of what Google, IBM, or General Motors might or might not do. Or, at least, wait until they make the threat of non-compliance openly.