From e7b772e65b5cedb6773a6ecc52cde6fb0bacdd79 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 26 Sep 2010 23:01:01 -0400 Subject: [PATCH] review --- ...r_https_in_urls_to_allow_serving_both.mdwn | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) 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 112112284..1547c39eb 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 @@ -82,3 +82,22 @@ you don't like my approach: 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? +> +> 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. +> +> 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. +> +> --[[Joey]] -- 2.45.2