[pmwiki-users] Protocol (https/http) included in $ScriptUrl

Patrick R. Michaud pmichaud at pobox.com
Thu Sep 7 18:21:08 CDT 2006

On Fri, Sep 08, 2006 at 12:23:31AM +0200, Bart wrote:
> | There's a number of issues related to this, also having to do with
> | relative versus absolute links.  They're described in:
> | 
> |     http://www.pmwiki.org/wiki/PITS/00526
> |     http://www.pmwiki.org/wiki/PITS/00527
> |     http://www.pmwiki.org/wiki/PITS/00595
> |     http://www.pmwiki.org/wiki/PITS/00619
> |     http://www.pmwiki.org/wiki/PITS/00764
> | 
> In a flash I realized that this was the way to also solve the http: https:
> switch :-)
> $ScriptUrl = $_SERVER['SCRIPT_NAME'];
> [...]
> What i try to illustrate with this story is cause of the absolute URL in
> pmwiki.php the new user busy with exploring Pmwiki's treasure box is easily
> set on the wrong trail getting things working in http and https, using to
> complex tricks with absolute URL's
> A decant configured server should just be able working with relative URL's
> Apache is :-)

Just for the record, the webserver configuration has very little to 
do with the overall issue.  It's the *browser* that has to know what 
to do with relative urls, so that it knows what server to contact 
in response to clicking a link, submitting a form, fetching a 
.gif or .css, or handling a 302 redirect.  By the time a browser 
sends a request to a webserver (such as Apache), the url is 
fully qualified.

There have been a couple of times in the past when I tried
switching PmWiki to default to a relative url instead of an
absolute one, and it generally ended up with something breaking
somewhere that couldn't easily be fixed.  So, I need to remember
all the things that broke, and for us to figure out how we might
handle each.

One of the big items that breaks is for sites doing CleanUrls
at the webserver root, because a relative url in this case means
that $ScriptUrl becomes "".  While that's okay for links between
pages, it can be a problem for forms, because instead of

    <form action="http://example.com" method=post>

we end up with

    <form action="" method="post">

which means to submit the form back to the current url as opposed
to the document root.  We can try to fix this with $ScriptUrl = '/';
but then all of our page links end up with two slashes at the front
('//Main/HomePage' instead of '/Main/HomePage') and we have a different
problem to deal with.

Still, anyone who is running a CleanUrls implementation ought to
be explicitly setting $ScriptUrl in config.php anyway, so perhaps we 
just tell them to always use an absolute url in this case.

The other issue that arises is dealing with HTTP redirects.  PmWiki
often has to redirect the browser to a different url; it normally
does this using a Location: header, as in

    Location: http://www.example.com/wiki/Main/HomePage

However, the HTTP protocol *requires* that the argument to Location:
be an absolute url, so if PmWiki uses a relative one here, as in

    Location: /wiki/Main/HomePage

then we aren't following the protocol and redirects don't function
properly.  (Actually, IIRC this one may in fact be an Apache issue,
but it's not one that can be easily fixed by a configuration setting
because it's a response url and not a request one.)

So, for redirects perhaps the solution is to have PmWiki look
at the value of $ScriptUrl, and convert it to an absolute url
if it isn't already one (using http:/https: and $_SERVER['HOST']
as appropriate).  That might work.

I seem to recall that there are a few other places where relative
urls have caused problems for us in the past, but I can't remember 
what they are at the moment.  Perhaps the best thing for me to do 
is to configure pmwiki.org with a relative url, and let's see what
breaks and what I can fix.  Then hopefully we can get enough volunteers
to also try relative urls on their sites, and after we have enough
success stories and very few people saying "it's breaking XYZ"
then we can change the default setting.

> I realize that this doesn't work for some setups (PITS/00526)
> But I suspect this is more a exception and likely a misconfiguration in
> server directives. 

Again, it's not a server configuration issue; and it occurs frequently
enough that I felt that absolute urls were the better setting.  This
is especially true for people who are installing PmWiki for the first
time, who are likely to get "turned off" by it if links or other
features aren't working properly for them "out of the box".  That
first impression is *really* important to me.

Thanks for the excellent post!


More information about the pmwiki-users mailing list