Use protocol-relative URIs if cgiurl and url differ only by authority (hostname)

[ikiwiki.git] / doc / todo / Protocol_relative_urls_for_stylesheet_linking.mdwn

diff --git a/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn b/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
index 99906a5dece4542a223995cdc2db0ed3604e9e58..0ab4814e6bc06cf198ce45dc7c9447157a434432 100644 (file)
--- a/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
+++ b/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
@@ -12,3 +12,29 @@ This can be fixed by setting the base wiki url to a protocol relative url, such
 but this breaks all sorts of things, like the 404 plugin and wiki rebuilds will throw the following perl warning several times:
 
     Use of uninitialized value in string ne at /usr/share/perl5/IkiWiki.pm line 586
+
+> With a vaguely recent ikiwiki, if your `url` and `cgiurl` settings have the
+> same hostname (e.g.
+> `url => "http://www.example.com", cgiurl => "https://www.example.com/ikiwiki.cgi"`),
+> most links are path-only (e.g. `/style.css`), and in particular,
+> CGI-generated pages should generate those links. This was the implementation of
+> [[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]].
+>
+> If your`$config{url}` and `$config{cgiurl}` have different hostnames (e.g.
+> `url => "http://wiki.example.com", cgiurl => "http://cgi.example.com/ikiwiki.cgi"`)
+> then you might still have this problem. In principle, IkiWiki could generate
+> protocol-relative URLs in this situation, but it isn't clear to me how
+> widely-supported those are.
+>
+>> HTML5 says protocol-relative URLs work, and they seem to be widely
+>> supported in practice, so I've changed the rule to: if the url and cgiurl
+>> share a scheme (protocol) but differ only by hostname, use `//foo/bar`
+>> protocol-relative URLs. This partially addresses this todo.
+>> I'm still thinking about what the right thing is for more complicated
+>> situations: see [[todo/design for cross-linking between content and CGI]].
+>> --[[smcv]]
+>
+> If you set both the `$config{url}` and `$config{cgiurl}` to https, but make
+> the resulting HTML available over HTTP as well as HTTPS, that should work
+> fine - accesses will be over http until the user either explicitly
+> navigates to https, or navigates to the CGI. --[[smcv]]