[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