X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/e05099d5cf70b3637c57b6584df3bdfddbb5e513..e65ce4f0937eaf622846c02a9d39fa7aebe4af12:/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn

diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
index cbd8c4da7..e2d9a5993 100644
--- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
+++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
@@ -60,7 +60,6 @@ becoming a problem for me. Is there anything I can do here? --[[Perry]]
 ----
 
 [[!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
@@ -108,11 +107,21 @@ you don't like my approach:
 >>
 >> 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.
 > 
@@ -130,3 +139,34 @@ you don't like my approach:
 >> 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...