----
+[[!toggle id="smcv-https" text="Some discussion of a rejected implementation, smcv/https."]]
+[[!toggleable id="smcv-https" text="""
+
[[!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
>>
>> 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.
>
>> 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
+
+"""]]
+
+----
+
+[[!template id=gitbranch branch=smcv/ready/localurl author="[[smcv]]"]]
+[[!tag patch]]
+
+OK, here's an alternative approach, closer in spirit to what was initially
+requested. I included a regression test for `urlto`, `baseurl` and `cgiurl`,
+now that they have slightly more complex behaviour.
+
+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. Most redirects, form actions, links etc.
+can safely use this form rather than the fully-absolute URL.
+
+The initial version of the branch had config options `local_url` and
+`local_cgiurl`, but they're now automatically computed by checking
+whether `url` and `cgiurl` are on the same server with the the same URL
+scheme. 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...
+
+I've tested this on a demo website with the CGI enabled, and it seems to
+work nicely (there might be bugs in some plugins, I didn't try all of them).
+The `$config{url}` and `$config{cgiurl}` are both HTTP, but if I enable
+`httpauth`, set `cgiauthurl` to a HTTPS version of the same site and log
+in via that, links all end up in the HTTPS version.
+
+New API added by this branch:
+
+* `urlto(x, y, 'local')` uses `$local_url` instead of `$config{url}`
+
+ > Yikes. I see why you wanted to keep it to 3 parameters (4 is too many,
+ > and po overrides it), but I dislike overloading the third parameter
+ > like that.
+ >
+ > There are fairly few calls to `urlto($foo, $bar)`, so why not
+ > make that always return the semi-local url form, and leave the third
+ > parameter for the cases that need a true fully-qualified url.
+ > The new form for local urls will typically be only a little bit longer,
+ > except in the unusual case where the cgiurl is elsewhere. --[[Joey]]
+
+* `IkiWiki::baseurl` has a new second argument which works like the
+ third argument of `urlto`
+
+* `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
+
+* `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters
+ except `cgiurl` and/or `local_cgiurl`
+
+Bugs:
+
+* I don't think anything except `openid` calls `cgiurl` without also
+ passing in `local_cgiurl => 1`, so perhaps that should be the default;
+ `openid` uses the `cgiurl` named parameter anyway, so there doesn't even
+ necessarily need to be a way to force absolute URLs? Any other module
+ that really needs an absolute URL could use
+ `cgiurl(cgiurl => $config{cgiurl}, ...)`,
+ although that does look a bit strange
+
+ > I agree that makes sense. --[[Joey]]
+
+* It occurs to me that `IkiWiki::cgiurl` could probably benefit from being
+ exported? Perhaps also `IkiWiki::baseurl`?
+
+ > Possibly, see [[firm_up_plugin_interface]]. --[[Joey]]
+
+* Or, to reduce use of the unexported `baseurl` function, it might make
+ sense to give `urlto` a special case that references the root of the wiki,
+ with a trailing slash ready to append stuff: perhaps `urlto('/')`,
+ with usage like this?
+
+ do_something(baseurl => urlto('/', undef, local)`);
+ do_something_else(urlto('/').'style.css');
+ IkiWiki::redirect(urlto('/', undef, 1));
+
+ > AFACIS, `baseurl` is only called in 3 places so I don't think that's
+ > needed. --[[Joey]]
sipb-www / ikiwiki.git / blobdiff