Why must Slashdot use // instead of http://?

[Dan Jacobson]

Why must Slashdot use "//..." instead of "http://...":
<a href="//science.slashdot.org/article.pl?sid=06/06/05/1039204">Astronauts
Lost Tools in Space, Forced to Improvise</a>

I saved http://slashdot.org/index.pl?light=1&noboxes=1 to disk for
later local reading and various browsers interpreted the //
differently: ftp:, file:.

[John Dunlop]

Dan Jacobson:

Why must Slashdot use "//..." instead of "http://...":
<a href="//science.slashdot.org/article.pl?sid=06/06/05/1039204">Astronauts
Lost Tools in Space, Forced to Improvise</a>
Can't answer that, sorry. FWIW, RFC3986 does say that network-path
references, as they're known, are 'rarely used' (sec. 4.2).

(Of course, you could pick holes in that URL for other, arguably more
serious, reasons: (i) the .pl, and (ii) the necessity and the form of
the query part.)

ObHTML, :-) did you omit CITE from your example or wasn't it in the
original?
I saved http://slashdot.org/index.pl?light=1&noboxes=1 to disk for
later local reading and various browsers interpreted the //
differently: ftp:, file:.

to be expected, if the conditions for the first three ways of
establishing a base URL aren't met:

| If none of the conditions described above apply, then the base
| URI is defined by the context of the application. As this
| definition is necessarily application-dependent, failing to define
| a base URI by using one of the other methods may result in
| the same content being interpreted differently by different
| types of applications.
|
| A sender of a representation containing relative references is
| responsible for ensuring that a base URI for those references
| can be established. Aside from fragment-only references,
| relative references can only be used reliably in situations where
| the base URI is well defined.

(sec. 5.1.4)

--
Jock

[Shawn K. Quinn]

begin quotation
from Dan Jacobson <ji*****@jidanni.org>
in message <87************@jidanni.org>
posted at 2006-06-10T20:11

Why must Slashdot use "//..." instead of "http://...":
<a href="//science.slashdot.org/article.pl?sid=06/06/05/1039204">Astronauts
Lost Tools in Space, Forced to Improvise</a>
Apparently some browsers, somewhere, let them "get away with it" due to
error recovery. This is why standards are made, and why it's in one's
best interest to follow them.
I saved http://slashdot.org/index.pl?light=1&noboxes=1 to disk for
later local reading and various browsers interpreted the //
differently: ftp:, file:.

It should be simple enough to fix this obviously broken document,
however, Slashdot should be made aware of the problem as well.

--
___ _ _____ |*|
/ __| |/ / _ \ |*| Shawn K. Quinn
\__ \ ' < (_) | |*| sk*****@speakeasy.net
|___/_|\_\__\_\ |*| Houston, TX, USA

[Dan]

Shawn K. Quinn wrote:

begin quotation
from Dan Jacobson <ji*****@jidanni.org>
in message <87************@jidanni.org>
posted at 2006-06-10T20:11

Why must Slashdot use "//..." instead of "http://...":
<a href="//science.slashdot.org/article.pl?sid=06/06/05/1039204">Astronauts
Lost Tools in Space, Forced to Improvise</a>

Apparently some browsers, somewhere, let them "get away with it" due to
error recovery. This is why standards are made, and why it's in one's
best interest to follow them.

It's not actually an "error", in its original context, though it's a
seldom-used URI form, and one which has no particularly good reason to
be used in this case (aside from saving a few bytes). What it means is
to access the hostname that follows the double slash, using the same
protocol as in the base URI of the document you are viewing. When that
document is accessed by http, then the link URIs would also be accessed
that way. This form of URI actually has its practical uses, in cases
where there are documents on different servers or domain names being
linked between where both the source and the destination documents
might be accessed via multiple protocols (e.g., both http and https, or
both http and ftp), and use the exact same path strings in both cases,
and you want the link to keep the user in the same protocol they were
in when they accessed the first document.

--
Dan