+patch
authorhttp://smcv.pseudorandom.co.uk/ <smcv@web>
Sun, 26 Sep 2010 21:53:00 +0000 (21:53 +0000)
committerJoey Hess <joey@kitenet.net>
Sun, 26 Sep 2010 21:53:00 +0000 (21:53 +0000)
doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn

index 63fd3d11dfce804b457578fb74509321e1c68fe1..d59bf15f03598902c921f534627613d507a5155a 100644 (file)
@@ -56,3 +56,27 @@ becoming a problem for me. Is there anything I can do here? --[[Perry]]
 > absolute urls that have been fixed since Brian filed the bug. --[[Joey]]  
 
 [[wishlist]]
+
+----
+
+[[!template id=gitbranch branch=smcv/https author="[[smcv]]"]]
+[[!tag patch]]
+
+For a while I've been using a configuration where each wiki has a HTTP and
+a HTTPS mirror, and updating one automatically updates the other, but
+that seems unnecessarily complicated. My `https` branch adds `https_url`
+and `https_cgiurl` config options which can be used to provide a HTTPS
+variant of an existing site; the CGI script automatically detects whether
+it was accessed over HTTPS and switches to the other one.
+
+This required some refactoring, which might be worth merging even if
+you don't like my approach:
+
+* change `IkiWiki::cgiurl` to return the equivalent of `$config{cgiurl}` if
+  called with no parameters, and change all plugins to indirect through it
+  (then I only need to change that one function for the HTTPS hack)
+
+* `IkiWiki::baseurl` already has similar behaviour, so change nearly all
+  references to the `$config{url}` to call `baseurl` (a couple of references
+  specifically wanted the top-level public URL for Google or Blogspam rather
+  than a URL for the user's browser, so I left those alone)