[pmwiki-users] HTTPS and pmwiki

Patrick R. Michaud pmichaud at pobox.com
Thu Sep 21 11:47:11 CDT 2006


On Thu, Sep 21, 2006 at 06:09:50PM +0200, Joachim Durchholz wrote:
> Patrick R. Michaud schrieb:
> > 
> > You need to set a custom value of $ScriptUrl that includes the 'https:'.
> > PmWiki currently doesn't detect this on its own.
> 
> For my projects, I found that the best way to avoid issues with 
> file-to-URL mappings, host name detection, and protocol detection was to 
> simply generate relative URLs.

While I agree, there are places where relative urls don't seem to
quite work.

> I.e. my HTML would contain
>    <a href="somewhere_else.html">
>    <a href="../some_other_group/sibling_page.html">
> instead of
>    <a href="http://path/to/project/this_group/somewhere_else.html">
>    <a href="http://path/to/project/some_other_group/sibling_page.html">
> 
> I'm not 100% sure how the the .. link would be handled though - servers 
> would have to be prepared to properly handle
>    http://path/to/project/this_group/../somewhere_else.html
> and that might indeed be a problem. (Is it?)

Servers don't normally handle the '..' references -- browsers
normally do that.  In other words, if we're on a page called
/project/this_group/some_page.html, and the browser sees

    <a href='../some_other_group/sibling_page.html'>

then it's the *browser* that converts the link to be
'/project/some_other_group/sibling_page.html' and sends that
to the server.  Thus the server doesn't see the '..' at all.

And that indicates why it's very difficult to do relative links--
doing so assumes we know what url the browser is currently at.
But we don't always know what address the browser is using.

For example, suppose a browser is looking at 
http://www.example.org/wiki/Main/HomePage, and it has
links to Main.WikiSandbox and PmWiki.Installation.  The relative
urls for these pages would need to be

    WikiSandbox                  ../PmWiki/Installation

Now let's suppose the same browser is looking at the same page
but using the url http://www.example.org/wiki (i.e., no pagename given).  
If we use the relative urls given above, then the browser ends up with links
to http://www.example.org/WikiSandbox and 
http://www.example.org/PmWiki/Installation, neither of which are
correct for our setup.

One could claim that the real problem in this scenario is that
a single page such as Main.HomePage shouldn't be available at more
than one url, but I don't think that can be realistically achieved
in the real world and the many contexts in which PmWiki finds itself.
And I think I can come up with other examples (forms submission, RSS 
feeds, etc.) where relative urls will impose other complications.

Another consideration is that computing a page's url is
also dependent on the setting of $EnablePathInfo -- if $EnablePathInfo
is set, then the browser's urls (hopefully) look like
http://www.example.com/wiki?n=Main.HomePage, and our relative urls 
would need to appear as 

    wiki?n=Main.WikiSandbox     wiki?n=PmWiki.Installation

In short, trying to generate relative urls that work in every possible
context and environment seems like it will introduce more problems
for more administrators than it could possibly eliminate.  Thus,
PmWiki goes with fully-qualified, absolute urls as its default,
and leaves it to the exceptional cases to adjust them as appropriate
(via a simple setting of $ScriptUrl).

Pm




More information about the pmwiki-users mailing list