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
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.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
--
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.
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.
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.
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?
(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)
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.
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 latency2) 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.
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvoCW0QNWfZG6Ntbw7M7eF-47NLAgzKUsZNkAPcPCGxeSQ%40mail.gmail.com.
In which case, spec please? :D
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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)
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)
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.
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.