Mailing List Archive: Wikipedia: Wikitech

Protocol relative URLs

Index | Next | Previous | View Threaded

gmaxwell at gmail

Jun 11, 2008, 8:35 AM

Post #1 of 4 (289 views)
Permalink

Protocol relative URLs

Anyone here have any experience with protocol relative URLs, that is
URLs of the form "//some.domain.org/file.ext"? URLs of this form are
uncommon but appear compliant with RFC 1808.

A possible application of protocol relative URLs for MediaWiki is that
they could be used remove the problem of needing duplicate parsings of
pages containing external (and cross-domain) links in order to support
HTTPS. With that issue out of the way the only impediment to high
performance SSL is connection setup which can be addressed with
dedicated crypto cards or crypto enhanced CPUs like Ultrasparc T1/T2.

I've confirmed protocol relatives they work in the browsers I have
ready access to. Googling around I found
http://nedbatchelder.com/blog/200710/httphttps_transitions_and_relative_urls.html#comments
which claims "The HTML 2 spec references RFC 1808 which describes this
behavior, and was written in 1995. I know this syntax works in IE6,
IE7, FF2, and Safari 2 and 3. I don't know of any browsers in which it
doesn't work."

Anyone here have practical experience with URLs of this form?

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

brion at wikimedia

Jun 11, 2008, 11:04 AM

Post #2 of 4 (272 views)
Permalink

Re: Protocol relative URLs [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gregory Maxwell wrote:
> Anyone here have any experience with protocol relative URLs, that is
> URLs of the form "//some.domain.org/file.ext"? URLs of this form are
> uncommon but appear compliant with RFC 1808.
>
> A possible application of protocol relative URLs for MediaWiki is that
> they could be used remove the problem of needing duplicate parsings of
> pages containing external (and cross-domain) links in order to support
> HTTPS. With that issue out of the way the only impediment to high
> performance SSL is connection setup which can be addressed with
> dedicated crypto cards or crypto enhanced CPUs like Ultrasparc T1/T2.

Duplicate parsing honestly isn't much of an impediment here; the primary
impediment is just configuring things properly for virtual hosts and SSL
proxies on the same IPs that we run non-SSL on.

eg, we want https://en.wikipedia.org/wiki/Foobar to work, which requires:

* SSL proxies in each data center
* wildcart certs for each second-level domain
* appropriate connection setup for the certs to work; eg one public IP
per data center per second-level domain

We did some experimentation in this direction last year, but haven't
really got the ball rolling yet.

- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhQE6wACgkQwRnhpk1wk44qFACfT+Az1p2L8KsQ2eRH+36Cy6w2
3M0AnjvATCGDFgUt5L32yoPTQXMFlIN5
=qKC4
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

gmaxwell at gmail

Jun 11, 2008, 4:02 PM

Post #3 of 4 (264 views)
Permalink

Re: Protocol relative URLs [In reply to]

On Wed, Jun 11, 2008 at 2:04 PM, Brion Vibber <brion[at]wikimedia.org> wrote:
> Duplicate parsing honestly isn't much of an impediment here; the primary
> impediment is just configuring things properly for virtual hosts and SSL
> proxies on the same IPs that we run non-SSL on.

I'd think that 2x the memory usage / disk usage in caches would be
nothing to sneeze at... or the cpu cost of holding one cached copy and
replacing the URLs internally.

In any case, I've started testing protocol relatives. If they turn
out to be reliable then it's just a further enhancement. I'll let
you know when I have some results.

> eg, we want https://en.wikipedia.org/wiki/Foobar to work, which requires:
>
> * SSL proxies in each data center
> * wildcart certs for each second-level domain
> * appropriate connection setup for the certs to work; eg one public IP
> per data center per second-level domain
>
> We did some experimentation in this direction last year, but haven't
> really got the ball rolling yet.

Right, and the wildcard certs tend to be more expensive for who knows
what reason... :(
Cool enough.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

brion at wikimedia

Jun 11, 2008, 4:42 PM

Post #4 of 4 (264 views)
Permalink

Re: Protocol relative URLs [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gregory Maxwell wrote:
> On Wed, Jun 11, 2008 at 2:04 PM, Brion Vibber <brion[at]wikimedia.org> wrote:
>> Duplicate parsing honestly isn't much of an impediment here; the primary
>> impediment is just configuring things properly for virtual hosts and SSL
>> proxies on the same IPs that we run non-SSL on.
>
> I'd think that 2x the memory usage / disk usage in caches would be
> nothing to sneeze at... or the cpu cost of holding one cached copy and
> replacing the URLs internally.

Ehh, wouldn't hurt in theory but I'm always suspicious. :)

Consider also non-browser uses:

* search spiders
* RSS feed links
* screen-scraping goodies
* post-processing web tools such as online translators, kanji->furigana
converters, etc

Note also that the fully-qualified URL may be pulled by {{SERVERNAME}}
or {{FULLURL:}} in the middle of wikitext, and is used in the print
footer etc.

> In any case, I've started testing protocol relatives. If they turn
> out to be reliable then it's just a further enhancement. I'll let
> you know when I have some results.

Sweet... :D

>> * SSL proxies in each data center
>> * wildcart certs for each second-level domain
> ...
> Right, and the wildcard certs tend to be more expensive for who knows
> what reason... :(

Otherwise people would buy one wildcard cert instead of two or three
individual-host certs, and the CAs would make less money... :D

- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhQYtgACgkQwRnhpk1wk45M/wCfamv2BnhTGTL29Gn/roknDWm1
DlEAnjxqPHovWj65n1wUKi3G4RhtoITS
=N8CK
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com