> absolute urls that have been fixed since Brian filed the bug. --[[Joey]]
[[wishlist]]
+
+----
+
+[[!template id=gitbranch branch=smcv/https author="[[smcv]]"]]
+
+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)
+
+--[[smcv]]
+
+> The justification for your patch seems to be wanting to use a different
+> domain, like secure.foo.com, for https? Can you really not just configure
+> both url and cgiurl to use `https://secure.foo.com/...` and rely on
+> relative links to keep users of `http://insecure.foo.com/` on http until
+> they need to use the cgi?
+
+>> My problem with that is that uses of the CGI aren't all equal (and that
+>> the CA model is broken). You could put CGI uses in two classes:
+>>
+>> - websetup and other "serious" things (for the sites I'm running, which
+>> aren't very wiki-like, editing pages is also in this class).
+>> I'd like to be able to let privileged users log in over
+>> https with httpauth (or possibly even a client certificate), and I don't
+>> mind teaching these few people how to do the necessary contortions to
+>> enable something like CACert.
+>>
+>> - Random users making limited use of the CGI: do=goto, do=404, and
+>> commenting with an OpenID. I don't think it's realistic to expect
+>> users to jump through all the CA hoops to get CACert installed for that,
+>> which leaves their browsers being actively obstructive, unless I either
+>> pay the CA tax (per subdomain) to get "real" certificates, or use plain
+>> http.
+>>
+>> On a more wiki-like wiki, the second group would include normal page edits.
+>>
+>>> I see your use case. It still seems to me that for the more common
+>>> case where CA tax has been paid (getting a cert that is valid for
+>>> multiple subdomains should be doable?), having anything going through the
+>>> cgiurl upgrade to https would be ok. In that case, http is just an
+>>> optimisation for low-value, high-aggregate-bandwidth type uses, so a
+>>> little extra https on the side is not a big deal. --[[Joey]]
+>>
+>> Perhaps I'm doing this backwards, and instead of having the master
+>> `url`/`cgiurl` be the HTTP version and providing tweakables to override
+>> these with HTTPS, I should be overriding particular uses to plain HTTP...
+>>
+>> --[[smcv]]
+>>>
+>>> Maybe, or I wonder if you could just use RewriteEngine for such selective
+>>> up/downgrading. Match on `do=(edit|create|prefs)`. --[[Joey]]
+
+> I'm unconvinced.
+>
+> `Ikiwiki::baseurl()."foo"` just seems to be asking for trouble,
+> ie being accidentially written as `IkiWiki::baseurl("foo")`,
+> which will fail when foo is not a page, but some file.
+
+>> That's a good point. --s
+
+> I see multiple places (inline.pm, meta.pm, poll.pm, recentchanges.pm)
+> where it will now put the https url into a static page if the build
+> happens to be done by the cgi accessed via https, but not otherwise.
+> I would rather not have to audit for such problems going forward.
+
+>> Yes, that's a problem with this approach (either way round). Perhaps
+>> making it easier to run two mostly-synched copies like I was previously
+>> doing is the only solution... --s
+
+----
+
+**warning: untested branch ** [[!template id=gitbranch branch=smcv/localurl author="[[smcv]]"]]
+
+OK, here's an alternative approach, closer in spirit to what was initially
+requested. I haven't tested this at all (it's getting rather late in UK time)
+and it will probably be rebased later, but I've referenced it here as a proof of
+concept.
+
+The idea is that in the common case, the CGI and the pages will reside on the
+same server, so they can use "semi-absolute" URLs (`/ikiwiki.cgi`, `/style.css`,
+`/bugs/done`) to refer to each other. My branch adds config options which
+could be set as follows for ikiwiki.info or any branchable.com site:
+
+* local_url: /
+* local_cgiurl: /ikiwiki.cgi
+
+Most redirects, form actions, links etc. can safely use this form rather than
+the fully-absolute URL. If not configured, these options default to the
+corresponding absolute URL, which is would also be correct for unusual sites
+where the CGI and the pages aren't on the same server.
+
+(In theory you could use things like `//static.example.com/wiki/` and
+`//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https
+while switching server, but I don't know how consistently browsers
+suppot that.)
+
+"local" here is short for "locally valid", because these URLs are neither
+fully relative nor fully absolute, and there doesn't seem to be a good name
+for them...