3 ms·
Is there any reason that: <link rel="dns-prefetch" href="//fonts.googleapis.com"> is using a protocol-relative URL, or any URL at all? Since we're controlli
by pyre 13y ago
Is there any reason that:
<link rel="dns-prefetch" href="//fonts.googleapis.com">
is using a protocol-relative URL, or any URL at all? Since we're controlling a DNS lookup, we would only care about the FQDN.
- narsil 13y agoBased on the spec ( http://www.w3.org/TR/html5/document-metadata.html#the-link-element http://www.w3.org/TR/html5/document-metadata.html#the-link-e... ) requiring a valid URL ( http://www.w3.org/TR/html5/infrastructure.html#valid-url http://www.w3.org/TR/html5/infrastructure.html#valid-url ) it would interpret it as a relative link to a path "fonts.googleapis.com" if you didn't specify '//' to indicate it was absolute. I don't agree that the spec should make an exception when rel is "dns-prefetch" and consider all href tags to be FQDNs or similar.
- tracker1 13y agoFor that matter, I'm not sure how much this feature actually helps... I know there is a cost to a lot of dns lookups.. but having the dns-prefetch in the header along with the actual link to the css likely won't help much... it might help a bit with script includes at the bottom of the page though... Also, a lot of the other bits aren't supported on IE 8/9 which is optimistically 1/3-1/2 the users on a lot of websites... it's worth doing, but doesn't mean you can/should forgo server-side checks/code. I find a lot of the client/server frameworks that are client-centric people are coming up with that do no input validation server-side to be more dangerous than a lot of older frameworks. It's like SQL injection issues all over again.