> absolute urls that have been fixed since Brian filed the bug. --[[Joey]]
[[wishlist]]
+
+----
+
+[[!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]]"]]
+
+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
+
+"""]]
+
+----
+
+[[!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
+support 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 seemed to
+work nicely (there might be bugs in some plugins, I didn't try all of them).
+The branch at [[todo/use secure cookies for SSL logins]] goes well with
+this one.
+
+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]]
+
+ >> So, have urlto(x, y) use `$local_url`? There are few calls, but IMO
+ >> they're for the most important things - wikilinks, img, map and
+ >> other ordinary hyperlinks. Using `$local_url` would be fine for
+ >> webserver-based use, but it does stop you browsing your wiki's
+ >> HTML over `file:///` (unless you set that as the base URL, but
+ >> then you can't move it around), and stops you moving simple
+ >> outputs (like the docwiki!) around.
+ >>
+ >> I personally think breaking the docwiki is enough to block that.
+ >>
+ >>> Well, the docwiki doesn't have an url configured at all, so I assumed
+ >>> it would need to fall back to current behavior in that case. I had
+ >>> not thought about browsing wiki's html files though, good point.
+ >>
+ >> How about this?
+ >>
+ >> * `urlto($link, $page)` with `$page` defined: relative
+ >> * `urlto($link, undef)`: local, starts with `/`
+ >> * `urlto($link)`: also local, as a side-effect
+ >> * `urlto($link, $anything, 1)` (but idiomatically, `$anything` is
+ >> normally undef): absolute, starts with `http[s]://`
+ >>
+ >> --[[smcv]]
+ >>
+ >>> That makes a great deal of sense, bravo for actually removing
+ >>> parameters in the common case while maintaining backwards
+ >>> compatability! --[[Joey]]
+ >>>
+ >>>> Done in my `localurl` branch; not tested in a whole-wiki way
+ >>>> yet, but I did add a regression test. I've used
+ >>>> `urlto(x, undef)` rather than `urlto(x)` so far, but I could
+ >>>> go back through the codebase using the short form if you'd
+ >>>> prefer. --[[smcv]]
+ >>>
+ >>> It does highlight that it would be better to have a
+ >>> `absolute_urlto($link)` (or maybe `absolute(urlto($link))` )
+ >>> rather than the 3 parameter form. --[[Joey]]
+ >>>
+ >>> Possibly. I haven't added this.
+
+* `IkiWiki::baseurl` has a new second argument which works like the
+ third argument of `urlto`
+
+ > I assume you have no objection to this --[[smcv]]
+
+ >> It's so little used that I don't really care if it's a bit ugly.
+ >> (But I assume changes to `urlto` will follow through here anyway.)
+ >> --[[Joey]]
+
+ >>> I had to use it a bit more, as a replacement for `$config{url}`
+ >>> when doing things like referencing stylesheets or redirecting to
+ >>> the top of the wiki.
+ >>>
+ >>> I ended up redoing this without the extra parameter. Previously,
+ >>> `baseurl(undef)` was the absolute URL; now, `baseurl(undef)` is
+ >>> the local path. I know you objected to me using `baseurl()` in
+ >>> an earlier branch, because `baseurl().$x` looks confusingly
+ >>> similar to `baseurl($x)` but has totally different semantics;
+ >>> I've generally written it `baseurl(undef)` now, to be more
+ >>> explicit. --[[smcv]]
+
+* `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
+
+ > Now changed to always use the `$local_cgiurl`. --[[smcv]]
+
+* `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters
+ except `cgiurl` and/or `local_cgiurl`
+
+ > I assume you have no objection to this --[[smcv]]
+ >
+ >> Nod, although I don't know of a use case. --[[Joey]]
+
+ >>> The use-case is that I can replace `$config{cgiurl}` with
+ >>> `IkiWiki::cgiurl()` for things like the action attribute of
+ >>> forms. --[[smcv]]
+
+Fixed 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]]
+
+ >> I'm not completely sure whether you're agreeing with "perhaps do this"
+ >> or "that looks too strange", so please disambiguate:
+ >> would you accept a patch that makes `cgiurl` default to a local
+ >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]]
+
+ >>> Yes, I absolutely think it should default to local. (Note that
+ >>> if `absolute()` were implemented as suggested above, it could also
+ >>> be used with cgiurl if necessary.) --[[Joey]]
+
+ >>>> Done (minus `absolute()`). --[[smcv]]
+
+Potential future things:
+
+* It occurs to me that `IkiWiki::cgiurl` could probably benefit from being
+ exported? Perhaps also `IkiWiki::baseurl`?
+
+ > Possibly, see [[firm_up_plugin_interface]]. --[[Joey]]
+
+ >> Not really part of this branch, though, so wontfix (unless you ask me
+ >> to do so). --[[smcv]]
+
+* 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]]
+
+ >> OK, wontfix. For what it's worth, my branch has 6 uses in IkiWiki
+ >> core code (IkiWiki, CGI, Render and the pseudo-core part of editpage)
+ >> and 5 in plugins, since I used it for things like redirection back
+ >> to the top of the wiki --[[smcv]]
sipb-www / ikiwiki.git / blobdiff