ikiwiki/doc/bugs/relative_links.mdwn

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.

-- Brian May

> 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]]

>> 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

>>> 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]]

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.
web commit by https://brian.may.myopenid.com/: relative links 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.`

web commit by https://brian.may.myopenid.com/ 2008-02-15 10:10:08 +01:00			`-- Brian May`
er, what absolute links? 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]]`
web commit by https://brian.may.myopenid.com/ 2008-02-15 10:10:08 +01:00
web commit by https://brian.may.myopenid.com/: simplify response 2008-02-16 09:37:29 +01: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`
user configuration error 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]]`

web commit by http://brian.may.myopenid.com/: work around not solution 2008-02-26 00:16:59 +01: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.