Support for protocol-relative URLs (tracking)
OpenPublic

Assigned To
None
Priority
Low
Author
brion
Blocks
T21270: Relative URIs in interwiki links table break interwiki transclusion
T4007: Tracking bug (tracking)
T20664: Relative URIs in interwiki links table causes failed redirects
Blocked By
T63556: captcha whitelist does not work for protocol-relative URLs
T43888: Parser doesn't support protocol relative external links in free link syntax
T38639: magicLinkCallback does not support protocol-relative URLs
T35030: Special:LinkSearch does not display results for protocol relative URLs
T35010: External links using {{fullurl:}} are saved twice into externallinks table
T34951: Storing of web links with absolute protocol to the own protocol relative server
T33293: check protocol in Special:UserLogin
T33294: allow protocol-relative URLs in $wgCaptchaWhitelist
T33284: {{fullurl:TEST}} doesn't create links anymore
T33181: MediaWiki mailer sends protocol-relative URLs on en.wp
T33180: WikiLove should not fail in if wgServer is protocol-relative
T33176: {{SERVERNAME}} variable does not strip // for protocol relative urls
T32922: DumpHTML "Latest revision" link oddities with protocol-relative URLs
T34440: Link to mediawiki.org in extension description should be protocol-relative
T32792: Protocol-relative URLs cause complete breakage of Squid purge during upload, action=purge, etc.
T34371: SiteMatrix should use protocol relative links
T32733: Wikimedia 404 Error shouldn't hardcode http
T32682: Link icon inconsistencies when using protocol relative URLs
T36107: printfooter "Retrieved from" url isn't protocol relative
T34220: make hints to MediaWiki.org in messages protocol relative
T34219: Make $wgUseInstantCommons protocol relative
T34050: GlobalUsage does not use protocol-relative URLs
T39138: Search not working correctly on the "Database error" page (Google sitesearch doesn't support protocol relative urls)
T32236: Protocol-relative URLs in double brackets parsed as internal links instead of external links surrounded by literal brackets
T33721: LinkSearch can't find protocol-relative links
T33681: Special:Cite displays protocol relative URLs if $wgServer is relative
T33667: action=parse doesn't respect protocol (uses http even when called over https)
T31993: E-mail notification should work with protocol relative urls
T31992: Display name broken if server has relative protocol
T35471: $wgCookieSecure = 'detect' fails when $wgServer is protocol-relative
T33644: GlobalUsage should use protocol-relative links
T31977: Description url in imageinfo outputs protocol relative urls
T31976: protocol relative uri for meta edituri
T31854: External link search and protocol-relative URLs
T35269: protocol relative urls do not have "secure" pad-lock icon when browsing from https and are thus secure links
T33437: https://www.mediawiki.org/xml/api/ shouldn't have links to http
T33428: Interwiki map update (protocol relative)
T31649: Use relative links (or, do not create unsecure links for users on secure server)
T33363: ImageMagick file comment has a protocol-relative URL
T33354: LQT should not give protocol relative URLs when the user click on "Link To"
T33355: Logging out from "https" wikis shouldn't log out from "http"
T33322: Retrievedfrom URI in print footer is not using httpS on secure server
T31497: Parser doesn't support protocol relative external links in single-bracketed syntax
Subscribers
brion, TheDJ, Krinkle and 3 others
Projects
Reference
bz20342
Description

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.)


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52253

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz20342.
brion created this task.Via LegacyAug 21 2009, 7:09 PM
Chad added a comment.Via ConduitMar 17 2010, 12:23 AM

Fixed up wfExpandUrl() to accept protocol-relative URIs in r63848.

bzimport added a comment.Via ConduitSep 17 2010, 3:15 PM

ayg wrote:

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

bzimport added a comment.Via ConduitMay 23 2011, 10:29 PM

gmaxwell wrote:

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."

Catrope added a comment.Via ConduitJul 13 2011, 12:23 AM

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.

TheDJ added a comment.Via ConduitOct 1 2011, 12:54 PM

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>

Krinkle added a comment.Via ConduitMay 9 2012, 2:13 AM

@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.

Aklapper changed the status of blocking task T35030: Special:LinkSearch does not display results for protocol relative URLs from "Open" to "Stalled".Via WebNov 25 2014, 7:47 PM
Chad removed a subscriber: Chad.Via WebNov 25 2014, 8:01 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.