Last modified: 2014-02-19 21:19:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T22342, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20342 - Support for protocol-relative URLs (tracking)
Support for protocol-relative URLs (tracking)
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: tracking
Depends on: 30682 33010 33030 29497 29649 29854 29976 29977 29992 29993 30236 30733 30792 30922 31176 31180 31181 31284 31293 31294 31322 31354 31355 31363 31428 31437 31644 31667 31681 31721 32050 32219 32220 32371 32440 32951 33269 33471 34107 36639 37138 41888 61556
Blocks: tracking 18664 19270
  Show dependency treegraph
 
Reported: 2009-08-21 19:09 UTC by Brion Vibber
Modified: 2014-02-19 21:19 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2009-08-21 19:09:17 UTC
As has been poked around the lists for a while, there's some interest in more active use of protocol-relative URLs (eg, '//upload.wikimedia.org/path/to/file.png' instead of 'http://upload.wikimedia.org/path/to/file.png').

Touted benefits include:
* ability to reference on-site links, sister-site links, and sister-site media references with the current protocol without having to render and cache separately for HTTP and HTTPS (but this requires that the URLs be otherwise identical! Would not be compatible with our current secure.wikimedia.org scheme, for instance)
* saving 5-6 bytes each for many of those external URL references

Browser compatibility seems reasonably stable for those who have been testing it, but there are lots of gotchas as MediaWiki doesn't cleanly support this yet.

A few notes offhand:
* wfExpandUrl and numerous other places assume any URL starting with "/" is relative to the current _host_ and will prepend '$wgServer' to it.
* there will be various places where we need to explicitly use a complete URL including the protocol, such as when creating emails, HTML or RSS feeds to use externally
* Uses of {{fullurl:}} {{SERVER}} etc in wikitext assume that the result is ok for use in wikitext as links; currently I don't believe these will get picked up.

In general we also probably want MW to know when it needs to make an HTTP reference and when an HTTPS reference, and generate those explicitly at times. (Eg a login link should always be HTTPS; some interwikis might take both HTTP and HTTPs while others might only take one or the other.)
Comment 1 Chad H. 2010-03-17 00:23:14 UTC
Fixed up wfExpandUrl() to accept protocol-relative URIs in r63848.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-09-17 15:15:28 UTC
Relevant IE bug:

http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

IE7 and 8 will download stylesheets with protocol-relative URLs twice.  Weird, but true.  It's fixed in IE9:

http://blogs.msdn.com/b/ieinternals/archive/2010/09/15/ie9-beta-minor-change-list.aspx
Comment 3 Gregory Maxwell 2011-05-23 22:29:51 UTC
Re, the double load bug in IE.  It sounds like it's not _that_ bad of an issue, since it only happens when the resource is not cached (on the first request):

According to Eric Lawrence from Microsoft:

"The reason that the problem appears intermittently isn’t related to Fiddler, but instead to timing.

Internal to Trident, the download queue has “de-duplication” logic to help ensure that we don’t download a single resource multiple times in parallel.

Until recently, that logic had a bug for certain resources (like CSS) wherein the schema-less URI would not be matched to the schema-specified URI and hence you’d end up with two parallel requests.

Once the resource is cached locally, the bug no longer repros because both requests just pull the cached local file."
Comment 4 Roan Kattouw 2011-07-13 00:23:14 UTC
This seems to be pretty solid now. I've added support for using protocol-relative URLs in wikitext in r91663 and r92005, support for protocol-relative URLs in wfParseUrl() in r92024 and support for protocol-relative values of $wgServer in wfExpandUrl() in r92028.

Now it's just a question of expanding URLs in API output (and other non-UI things such as RSS) in a few more places. External link search is probably gonna be broken, but that's bug 29854. This bug can be closed.
Comment 5 Derk-Jan Hartman 2011-10-01 12:54:05 UTC
I only have two elements left in https://en.wikipedia.org and https://nl.wikipedia.org


<link rel="apple-touch-icon" href="http://en.wikipedia.org/apple-touch-icon.png" />

and 

<div class="printfooter">
Retrieved from "<a href="http://en.wikipedia.org/wiki/Special:Watchlist">http://en.wikipedia.org/wiki/Special:Watchlist</a>"</div>
Comment 6 Krinkle 2012-05-09 02:13:26 UTC
@Derk-Jan Hartman: wgAppleTouchIcon has been fixed and deployed.

The latter is imho a pending WONTFIX. It is only shown on print, and on print canonical URLs are used.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links