diff options
author | http://smcv.pseudorandom.co.uk/ <smcv@web> | 2013-09-24 11:01:09 -0400 |
---|---|---|
committer | admin <admin@branchable.com> | 2013-09-24 11:01:09 -0400 |
commit | ba17b7b96b72c9e9b42a24e6e58441e0710c433a (patch) | |
tree | 3f3daeeb506823e1f18456e10dc7c7de42e5f03b | |
parent | 961afd3446ca822d2f329c8034ad300dd92327db (diff) | |
download | ikiwiki-ba17b7b96b72c9e9b42a24e6e58441e0710c433a.tar ikiwiki-ba17b7b96b72c9e9b42a24e6e58441e0710c433a.tar.gz |
-rw-r--r-- | doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn b/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn index 99906a5de..ccbaf4e73 100644 --- a/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn +++ b/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn @@ -12,3 +12,21 @@ 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. +> +> 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]] |