Intent to Ship: Link header support for <link rel=dns-prefetch>

[Yoav Weiss]

Contact emails

yo...@yoav.ws / yoav....@akamai.com

Spec

https://tools.ietf.org/html/rfc5988

The spec is fairly old so did not go through the TAG review process

Summary

Add Link header support for the dns-prefetch feature.

Link to “Intent to Implement” blink-dev discussion

No "Intent to Implement" discussion, unfortunately. There was a related discussion about rel=preconnect.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Compatibility Risk

Low. This has been implemented in Firefox for a long while now.

Firefox: Full support.

Safari: No public signals.

IE: No public signals.

OWP launch tracking bug

crbug.com/503575

Entry on the feature dashboard

This is a fairly minor change, so I don't think an entry on the dashboard is needed. Let me know if I'm wrong about that.

[Ryan Sleevi]

On Tue, Jun 23, 2015 at 5:19 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Contact emails

yo...@yoav.ws / yoav....@akamai.com

Spec

https://tools.ietf.org/html/rfc5988

The spec is fairly old so did not go through the TAG review process

Doesn't seem to specify dns-prefetch at all.

Neither is dns-prefetch registered in the IANA registry, per the process 5988 sets out ( http://www.iana.org/assignments/link-relations/link-relations.xhtml )

So uh, where's the spec? :) 

[Yoav Weiss]

Yeah, the spec specifies Web Linking in general, nothing dns-prefetch specific.

dns-prefetch was never specified, and is being replaced by the (significantly better) preconnect relation. 

[Chris Bentzel]

If its not specified and being replaced, perhaps we shouldn't introduce this?

Are the plans for preconnect that the U-A can fall back to just doing DNS resolution if it wants and not necessarily having to go through the full connect flow? We do have to deal with the case where the U-A straight out ignores the preconnect hint.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACj%3DBEhYaXztZowUfubbLuF9mqfCGV7BC1%2BXd-h0mKz4wQ-eLA%40mail.gmail.com.

[Ryan Sleevi]

On Tue, Jun 23, 2015 at 7:06 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Yeah, the spec specifies Web Linking in general, nothing dns-prefetch specific.

dns-prefetch was never specified, and is being replaced by the (significantly better) preconnect relation. 

So doesn't that mean there is both a compatibility and spec risk?

Compatibility - Support for dns-prefetch can't be added consistently and may result in different behaviours

Spec - That it's specified how Link headers behave (versus link-elements), but that there's no spec about how Chrome should behave with such a header?

I guess, as you note, we've shipped dns-prefetch and that's out there, in the wild, and in use, but I just want to make sure we're fully disclosing the downsides, rather than just spinning it as a low-risk change :)

Should we, alternatively, do an Intent to Deprecate for rel=dns-prefetch, given these reasons, and given that rel=preconnect suggests a more viable path?

(and I guess I'm not 100% sure that rel=preconnect is better, since rel=preconnect requires knowing the cross-origin context it'll be used in, while rel=dns-prefetch would allow you to amoritize some of the costs w/o having to contemplate the cross-origin context, making it easier to deploy)

[Ilya Grigorik]

On Tue, Jun 23, 2015 at 3:28 PM, Chris Bentzel <cben...@chromium.org> wrote:

Are the plans for preconnect that the U-A can fall back to just doing DNS resolution if it wants and not necessarily having to go through the full connect flow? We do have to deal with the case where the U-A straight out ignores the preconnect hint.

Yes, that's a valid strategy for preconnect.

 

On Tue, Jun 23, 2015 at 3:51 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Tue, Jun 23, 2015 at 7:06 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Yeah, the spec specifies Web Linking in general, nothing dns-prefetch specific.

dns-prefetch was never specified, and is being replaced by the (significantly better) preconnect relation. 

Should we, alternatively, do an Intent to Deprecate for rel=dns-prefetch, given these reasons, and given that rel=preconnect suggests a more viable path?

FWIW, if we go down this path, I'd propose an alternative... Namely, automatically "upgrade" existing dns-prefetch hints to "preconnect": there are no (legitimate) cases where you want to do the DNS prefetch without connecting to the same origin; with preconnect shipped, the general guidance will be to replace all of those with preconnect's anyway.

 

(and I guess I'm not 100% sure that rel=preconnect is better, since rel=preconnect requires knowing the cross-origin context it'll be used in, while rel=dns-prefetch would allow you to amoritize some of the costs w/o having to contemplate the cross-origin context, making it easier to deploy)

Yes, but that extra bit of thought affords a significantly higher (potential) win: it can save you the TCP and TLS handshakes. 

ig

[Ryan Sleevi]

On Tue, Jun 23, 2015 at 10:41 AM, Ilya Grigorik <igri...@google.com> wrote:

FWIW, if we go down this path, I'd propose an alternative... Namely, automatically "upgrade" existing dns-prefetch hints to "preconnect": there are no (legitimate) cases where you want to do the DNS prefetch without connecting to the same origin; with preconnect shipped, the general guidance will be to replace all of those with preconnect's anyway.

I'm not sure I'd buy into that argument. Saying "no legitimate cases" is a bit wrong:

1) When you don't know / don't want to specify whether or not it's a cross-origin preconnect (due to socket pools) but still want to benefit from the improved latency

2) When Chrome's "preconnect" behaviour negatively affects your server (and yes, we see bug reports every quarter on this), but where you still want to be able to take advantage of improved dns times.

3) considering that "rel=preconnect" can have real data costs for users on mobile, rel=dns-prefetch may be either 'free rated' (by virtue of going to the mobile carrier's DNS provider) or offer a more lightweight policy nob for sites without causing users to do the full handshake until they take an affirmative action.

It sounds like your solution to #2 is "Oh well, upgrade your server", and I'm not sure if that's an entirely fair/valid response (even if it's one I may have made in the past). Just feels overly dismissive towards users and developers to say there's no use case, and that rel=preconnect should be enough for everybody (like 64K? :P)

  

(and I guess I'm not 100% sure that rel=preconnect is better, since rel=preconnect requires knowing the cross-origin context it'll be used in, while rel=dns-prefetch would allow you to amoritize some of the costs w/o having to contemplate the cross-origin context, making it easier to deploy)

Yes, but that extra bit of thought affords a significantly higher (potential) win: it can save you the TCP and TLS handshakes. 

That doesn't mean it's strictly better. It means you can save costs - if you get it right. If you don't, it can add costs - not only in load time, but to users' data usage. 

[Matt Menke]

On Tue, Jun 23, 2015 at 1:52 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Tue, Jun 23, 2015 at 10:41 AM, Ilya Grigorik <igri...@google.com> wrote:

FWIW, if we go down this path, I'd propose an alternative... Namely, automatically "upgrade" existing dns-prefetch hints to "preconnect": there are no (legitimate) cases where you want to do the DNS prefetch without connecting to the same origin; with preconnect shipped, the general guidance will be to replace all of those with preconnect's anyway.

I'm not sure I'd buy into that argument. Saying "no legitimate cases" is a bit wrong:

1) When you don't know / don't want to specify whether or not it's a cross-origin preconnect (due to socket pools) but still want to benefit from the improved latency

2) When Chrome's "preconnect" behaviour negatively affects your server (and yes, we see bug reports every quarter on this), but where you still want to be able to take advantage of improved dns times.

3) considering that "rel=preconnect" can have real data costs for users on mobile, rel=dns-prefetch may be either 'free rated' (by virtue of going to the mobile carrier's DNS provider) or offer a more lightweight policy nob for sites without causing users to do the full handshake until they take an affirmative action.

Another situation:  Preconnected sockets aren't kept alive long, so if you aren't going to use them in the next 10 seconds, they're a bad idea.  DNS caches can (In theory) keep useful information around quite a bit longer.  If a user visits a site, it may make sense to do a DNS prefetch on all its sub-domains, even if not all of them are needed for the particular page a user is visiting as a much simpler solution than trying to guess what the user will do in the next 10 seconds.

 

It sounds like your solution to #2 is "Oh well, upgrade your server", and I'm not sure if that's an entirely fair/valid response (even if it's one I may have made in the past). Just feels overly dismissive towards users and developers to say there's no use case, and that rel=preconnect should be enough for everybody (like 64K? :P)

  

(and I guess I'm not 100% sure that rel=preconnect is better, since rel=preconnect requires knowing the cross-origin context it'll be used in, while rel=dns-prefetch would allow you to amoritize some of the costs w/o having to contemplate the cross-origin context, making it easier to deploy)

Yes, but that extra bit of thought affords a significantly higher (potential) win: it can save you the TCP and TLS handshakes. 

That doesn't mean it's strictly better. It means you can save costs - if you get it right. If you don't, it can add costs - not only in load time, but to users' data usage. 

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvaUa4_U-Qn4OhHstXdysBgWm-SV6PJmQx7nRbRpoBcGmQ%40mail.gmail.com.

[Ilya Grigorik]

Fair enough, I think those are all compelling arguments in favor of keeping dns-prefetch.. And if we do, we should allow Link header use case, just as we plan to offer for preconnect and other hints.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvoCW0QNWfZG6Ntbw7M7eF-47NLAgzKUsZNkAPcPCGxeSQ%40mail.gmail.com.

[Ryan Sleevi]

In which case, spec please? :D

[Ilya Grigorik]

On Tue, Jun 23, 2015 at 7:21 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

In which case, spec please? :D

For <link rel=dns-prefetch>? The closest we have is our own design doc that motivated it: https://www.chromium.org/developers/design-documents/dns-prefetching. The Link header interop is outcome of: https://tools.ietf.org/html/rfc5988#section-5.

[Philip Jägenstedt]

Yoav, do you think we should have both dns-prefetch and preconnect as permanent parts of the platform? It sounds like there would be cases where doing only the DNS bit makes sense, but are the other browser vendors on board with this long-term plan? Also, who will be driving the spec work for this?

Somewhat off topic, but is there or will there be any API for pns-prefetch and/or preconnect? For a single-page app that has just switched to show the news headlines it fetched a while ago, it might make sense to prefetch or preconnect to the most likely destination, but there won't be any request on which to put the header. Perhaps the API is to just create and insert <link> elements?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Ryan Sleevi]

On Mon, Jun 29, 2015 at 9:44 AM, Yoav Weiss <yo...@yoav.ws> wrote:

I don't think it's needed.

The use-case that Ryan raised makes sense. If the destination host's usage has low probability, you may want to tone down from a full-fledged DNS+TCP+TLS connection. 

But, that can be covered by support for the `pr` attribute on the link element. (which is not covered by the current `preconnect` implementation but would be a future extension)

Without wanting to get too far in spec reviews, I don't think I'd agree with that conclusion, or that the API shape proposed is a good one :) It's unquestionably less semantic information to express as a floating point value from 0.0 - 1.0 how much you intend to "connect" to a site as a substitute for DNS resolution.

For a TCP connection, should you express .5 (assuming that TCP connections are "DNS resolve" and "TCP connect")? What about for an SSL connection - should it be .33 (assuming it's DNS -> TCP -> SSL)?

But what about proxies? They might be .25 (DNS[Proxy] -> TCP[proxy] -> SSL[proxy?] -> CONNECT[if HTTP])?

I'd be happy to see that discussed there, but I don't think it bodes well to suggest they're equivalent.

As a result, we really should be looking at "how do we spec this thing that multiple browsers have now implemented and people are using", without saying "This will all be replaced, so we don't need to spec it". If we do that, then I think it's sensible to expose more natural ways for developers to take advantage of that. But I don't think it'd be good to add more exposure to the Web Platform of a feature we haven't taken the time to sit down and spec :/

[Philip Jägenstedt]

On Mon, Jun 29, 2015 at 6:44 PM, Yoav Weiss <yo...@yoav.ws> wrote:

On Mon, Jun 29, 2015 at 1:53 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Yoav, do you think we should have both dns-prefetch and preconnect as permanent parts of the platform? It sounds like there would be cases where doing only the DNS bit makes sense, but are the other browser vendors on board with this long-term plan?

I don't think it's needed.

The use-case that Ryan raised makes sense. If the destination host's usage has low probability, you may want to tone down from a full-fledged DNS+TCP+TLS connection. 

But, that can be covered by support for the `pr` attribute on the link element. (which is not covered by the current `preconnect` implementation but would be a future extension)

Is this to say that you no longer wish to ship dns-prefetch, that we should ship it and later replace it by preconnect+pr, or something else? Sorry if I'm missing something :)

FWIW, a floating point attribute that determines how far the preconnect goes sounds odd. To get interoperability the exact limits would have be specified, at which point the number is just a magic string to get the desired behavior. Explicit labels for the useful levels seems more sound, to me.

Philip

[Yoav Weiss]

On Mon, Jun 29, 2015 at 9:00 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Mon, Jun 29, 2015 at 6:44 PM, Yoav Weiss <yo...@yoav.ws> wrote:

On Mon, Jun 29, 2015 at 1:53 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Yoav, do you think we should have both dns-prefetch and preconnect as permanent parts of the platform? It sounds like there would be cases where doing only the DNS bit makes sense, but are the other browser vendors on board with this long-term plan?

I don't think it's needed.

The use-case that Ryan raised makes sense. If the destination host's usage has low probability, you may want to tone down from a full-fledged DNS+TCP+TLS connection. 

But, that can be covered by support for the `pr` attribute on the link element. (which is not covered by the current `preconnect` implementation but would be a future extension)

Is this to say that you no longer wish to ship dns-prefetch, that we should ship it and later replace it by preconnect+pr, or something else? Sorry if I'm missing something :)

dns-prefetch is shipped. I thought that exposing it through a Link header would be trivial (The coding part of it certainly was, once everything was in place for preconnect). 

Since that's not the case, I've opened an issue on the resource hints spec. Let's consider this I2S "on pause" until further feedback on that issue.

FWIW, a floating point attribute that determines how far the preconnect goes sounds odd. To get interoperability the exact limits would have be specified, at which point the number is just a magic string to get the desired behavior. Explicit labels for the useful levels seems more sound, to me.

I'm not sure the parts determining how far does a preconnect go in uncertainty situations require interoperability. There's certainly no interoperability in the preconnect behavior browsers show without any hints.

[Philip Jägenstedt]

On Tue, Jun 30, 2015 at 9:55 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Mon, Jun 29, 2015 at 9:00 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Mon, Jun 29, 2015 at 6:44 PM, Yoav Weiss <yo...@yoav.ws> wrote:

On Mon, Jun 29, 2015 at 1:53 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Yoav, do you think we should have both dns-prefetch and preconnect as permanent parts of the platform? It sounds like there would be cases where doing only the DNS bit makes sense, but are the other browser vendors on board with this long-term plan?

I don't think it's needed.

The use-case that Ryan raised makes sense. If the destination host's usage has low probability, you may want to tone down from a full-fledged DNS+TCP+TLS connection. 

But, that can be covered by support for the `pr` attribute on the link element. (which is not covered by the current `preconnect` implementation but would be a future extension)

Is this to say that you no longer wish to ship dns-prefetch, that we should ship it and later replace it by preconnect+pr, or something else? Sorry if I'm missing something :)

dns-prefetch is shipped. I thought that exposing it through a Link header would be trivial (The coding part of it certainly was, once everything was in place for preconnect). 

Since that's not the case, I've opened an issue on the resource hints spec. Let's consider this I2S "on pause" until further feedback on that issue.

So sorry, I was indeed missing something important, that shipping <link rel=dns-prefetch> is yesteryears news:

https://bugs.webkit.org/show_bug.cgi?id=20690

http://bitsup.blogspot.se/2008/11/dns-prefetching-for-firefox.html

http://blogs.msdn.com/b/ieinternals/archive/2012/03/01/ie10-beta-consumer-preview-minor-changes-changelist.aspx

If dns-prefetch is added to Resource Hints and no browser vendors has a problem with it, then supporting it in the Link header seems unproblematic to me.

Philip

[Yoav Weiss]

dns-prefetch was just added to the Resource Hints spec. 

[Ryan Sleevi]

Thanks.

Added a comment to the existing issue - https://github.com/w3c/resource-hints/issues/31 - to make sure the privacy & implementation concerns are documented :)

That said, I think it's fine to add support for the header - now that there's a canonical place to discuss the implementation details and attendant issues. Philip, does that sound good to you as well?

[Philip Jägenstedt]

Yep, LGTM to ship!

[Ilya Grigorik]

On Sat, Jul 18, 2015 at 12:21 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Yep, LGTM to ship!

Great, we need 2 more! What say you, owners? :-)