Performance and RFC 2396
Jens O. Meiert, February 18, 2009 / February 28, 2009.
This entry is filed under Web Development.
RFC 2396 (1998) specifies that relative URIs like //foo get resolved as http://foo. This means, if you link a resource like http://example.ms/, @href could as well just point to //example.ms/.
Figure: An image that wouldn’t be there if @src couldn’t start with //.
Theoretically, this has two advantages: You can save a couple of characters per URI reference, and you may work around security alerts when juggling with and switching between http and https. But I’m saying that just to inspire performance critics who already and with great joy discussed omitting optional tags and advantages of HTML in general.
Since this part of RFC 2396, seen as a whole, is still relatively new to me feel free to correct me, as always. I’m just curious and love experimenting a bit. So after I verified all major browsers to support the // syntax I actually created a “honeypot” test page as well to see if that page gets indexed properly by search engines. Watch this space for the findings.
Update (February 28, 2009)
As it seems, all major search engines followed the “hidden” links to the RFC 2396/3986 test page I set up: Google was first, Yahoo, Microsoft’s Live Search, and Altavista followed over the last days. There’s a slim chance that the test might have been compromised, but there are no indicators whatsoever solidifying that concern.
Read More
Enjoy the most popular posts, probably including:
Comments
-
On February 18, 2009, 11:09 CET, Kroc Camen said:
Most excellent, I really look forward to your findings. This syntax will be especially pertinent to the regex I use for publishing.
-
On February 18, 2009, 21:49 CET, potherca said:
I come from a back-end development background myself and for the last year or so I’ve been delving deeper and deeper into the front-end. This is one of those fun little quirks I really enjoy to encounter… Just thinking out loud here, but I wonder how this compliments/collides with (for example) user-input validation?
Looking explicitly for ahttp://isn’t necessary… things could be greatly simplified. Links only need to be/(on-site) or//(off-site).What fun

Like the right honorable K. Camen, I to am looking forward to your findings… Keep us informed!
-
On February 18, 2009, 23:36 CET, Keith Bell said:
Jens, I wasn’t aware of that before. It’s interesting in a “maybe I’ll find a use for that one day” kind of way.
I wonder if the syntax is supported well by mobile user agents.
-
On February 19, 2009, 9:12 CET, Francesco said:
That’s pretty interesting! I’m looking always for ways to trim my code as much as possible. Looking foward to your results!
-
On February 23, 2009, 9:57 CET, Gunnar Bittersmann said:
Why do you refer to RFC 2396 which has been obsoleted by RFC 3986 for 4 years?
-
On February 23, 2009, 10:03 CET, Jens Meiert said:
Gunnar, maybe because RFCs just state what they make obsolete, not by what they became obsolete. Thanks for the friendly reference.
Let’s call this post “Performance and RFC 2396/3986” then, I like the idea of scoring twice. (In other words: So what?)
-
On February 23, 2009, 16:51 CET, Gunnar Bittersmann said:
Hm, funny. The HTML version of RFC 2396 lists “Obsoleted by: 3986” and “Updated by: 2732”; the plain text version does not.
-
On April 15, 2009, 20:29 CEST, Steven Black said:
Works in IE and Firefox. But Chrome resolves “//” as “file://”.