doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn

   1 For security reasons, ikiwiki.cgi should only be accessed via HTTPS, which is easy to set in the config, however each wiki page contains
   2
   3     <link rel="stylesheet" href="http://ikiwiki.info/style.css" type="text/css" />
   4     <link rel="stylesheet" href="http://ikiwiki.info/local.css" type="text/css" />
   5
   6 regardless of whether the site is accessed via HTTP or HTTPS, which causes most modern browsers to automatically disable javascript and complain about the site only being partially encrypted. Features such as the openID-selector stop working unless the user manually allows the browser to execute unsafe scripts on the site.
   7
   8 This can be fixed by setting the base wiki url to a protocol relative url, such as
   9
  10     //wiki.example.com
  11
  12 but this breaks all sorts of things, like the 404 plugin and wiki rebuilds will throw the following perl warning several times:
  13
  14     Use of uninitialized value in string ne at /usr/share/perl5/IkiWiki.pm line 586
  15
  16 > With a vaguely recent ikiwiki, if your `url` and `cgiurl` settings have the
  17 > same hostname (e.g.
  18 > `url => "http://www.example.com", cgiurl => "https://www.example.com/ikiwiki.cgi"`),
  19 > most links are path-only (e.g. `/style.css`), and in particular,
  20 > CGI-generated pages should generate those links. This was the implementation of
  21 > [[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]].
  22 >
  23 >> This wasn't actually the case if the schemes are different; but now
  24 >> IkiWiki will generate protocol-relative URLs if the CGI is https,
  25 >> the url is http and the hostname is the same (i.e. it assumes that the https
  26 >> equivalent of the url will also work). This is to prevent mixed-content
  27 >> issues, and partially addresses this todo item.
  28 >> --[[smcv]]
  29 >
  30 > If your`$config{url}` and `$config{cgiurl}` have different hostnames (e.g.
  31 > `url => "http://wiki.example.com", cgiurl => "http://cgi.example.com/ikiwiki.cgi"`)
  32 > then you might still have this problem. In principle, IkiWiki could generate
  33 > protocol-relative URLs in this situation, but it isn't clear to me how
  34 > widely-supported those are.
  35 >
  36 >> HTML5 says protocol-relative URLs work, and they seem to be widely
  37 >> supported in practice, so I've changed the rule to: if the url and cgiurl
  38 >> share a scheme (protocol) but differ only by hostname, use `//foo/bar`
  39 >> protocol-relative URLs. This partially addresses this todo.
  40 >> I'm still thinking about what the right thing is for more complicated
  41 >> situations: see [[todo/design for cross-linking between content and CGI]].
  42 >> --[[smcv]]
  43 >
  44 > If you set both the `$config{url}` and `$config{cgiurl}` to https, but make
  45 > the resulting HTML available over HTTP as well as HTTPS, that should work
  46 > fine - accesses will be over http until the user either explicitly
  47 > navigates to https, or navigates to the CGI. --[[smcv]]