2008-02-14 21:40:22 +01:00
|
|
|
It looks like all links in websites are absolute paths, this has some limitations:
|
|
|
|
|
|
|
|
* If connecting to website via https://... all links will take you back to http://
|
|
|
|
* Makes it harder to mirror website via HTML version, as all links have to be updated.
|
|
|
|
|
|
|
|
It would be good if relative paths could be used instead, so the transport method isn't changed unless specifically requested.
|
|
|
|
|
2008-02-15 10:10:08 +01:00
|
|
|
-- Brian May
|
2008-02-14 21:46:24 +01:00
|
|
|
|
|
|
|
> Er, which absolute links are you talking about? If you view the source
|
|
|
|
> to this page, you'll find links such as "../favicon.ico", "../style.css",
|
|
|
|
> "../../", and "../". The only absolute links are to CGIs and the w3c DTD.
|
|
|
|
> --[[Joey]]
|
2008-02-15 10:10:08 +01:00
|
|
|
|
2010-08-30 20:41:59 +02:00
|
|
|
>> The problem is within the CGI script. The links within the HTML page are all
|
|
|
|
>> absolute, including links to the css file. Having a http links within a HTML
|
|
|
|
>> page retrieved using https upset most browsers (I think). Also if I push cancel
|
|
|
|
>> on the edit page in https, I end up at at http page. -- Brian May
|
2008-02-24 23:01:37 +01:00
|
|
|
|
|
|
|
>>> Ikiwiki does not hardcode http links anywhere. If you don't want
|
|
|
|
>>> it to use such links, change your configuration to use https
|
|
|
|
>>> consistently. --[[Joey]]
|
|
|
|
|
2010-08-30 20:41:59 +02:00
|
|
|
Errr... That is not a solution, that is a work around. ikiwiki does not hard
|
|
|
|
code the absolute paths, but absolute paths are hard coded in the configuration
|
|
|
|
file. If you want to serve your website so that the majority of users can see
|
|
|
|
it as http, including in rss feeds (this allows proxy caches to cache the
|
|
|
|
contents and has reduced load requirements), but editing is done via https for
|
|
|
|
increased security, it is not possible. I have some ideas how this can be
|
|
|
|
implemented (as ikiwiki has the absolute path to the CGI script and the
|
|
|
|
absolute path to the destination, it should be possible to generate a relative
|
|
|
|
path from one to the other), although some minor issues still need to be
|
|
|
|
resolved. -- Brian May
|
|
|
|
|
|
|
|
I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are
|
|
|
|
also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems
|
|
|
|
surprising, as the change.tmpl file uses <TMPL_VAR BASEURL> which seems
|
|
|
|
to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL
|
|
|
|
set? -- Brian May
|
2008-04-11 01:54:38 +02:00
|
|
|
|
|
|
|
> The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]]
|
2008-10-02 21:12:57 +02:00
|
|
|
|
2010-08-30 20:41:59 +02:00
|
|
|
So I'm facing this same issue. I have a wiki which needs to be accessed on
|
|
|
|
three different URLs(!) and the hard coding of the URL from the setup file is
|
|
|
|
becoming a problem for me. Is there anything I can do here? --[[Perry]]
|
|
|
|
|
|
|
|
> I remain puzzled by the problem that Brian is discussing. I don't see
|
|
|
|
> why you can't just set the cgiurl and url to a https url, and serve
|
|
|
|
> the site using both http and https.
|
|
|
|
>
|
|
|
|
> Just for example, <https://kitenet.net/> is an ikiwiki, and it is accessible
|
|
|
|
> via https or http, and if you use https, links will remain on https (except
|
|
|
|
> for links using the cgi, which I could fix by changing the cgiurl to https).
|
|
|
|
>
|
|
|
|
> I think it's possible ikiwiki used to have some
|
|
|
|
> absolute urls that have been fixed since Brian filed the bug. --[[Joey]]
|
2010-08-05 02:38:44 +02:00
|
|
|
|
2008-10-02 21:12:57 +02:00
|
|
|
[[wishlist]]
|