[pmwiki-users] Protocol (https/http) included in $ScriptUrl
pmwiki-users at mediamatrix.nl
Fri Sep 8 05:42:07 CDT 2006
On Thu, Sep 07, 2006 at 06:21:08PM -0500, Patrick R. Michaud wrote:
| 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.
Totally right thanks for stating this, it's a important for this discussion to keep
that in mind.
Obvious on the Internet relative urls don't work, they have be fully qualified
by the webserver and the webbrowser.
But relative urls in webpages is a powerful tool to make things portable
across e.g. different machines, domains and protocols. As I precise the
situation the same is basically true for applications.
| 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.
Please correct me when I am wrong and please be not offended by the odd
way of my words, my English skills are not as good as I wished it would be
and I am a bit worried that my word can offend people when I try to put my
ideas in English words in a clear and short way. In the last weeks I have
been amazed time after time by the quality of communication, the swiftness
questions are answered and problems are taken care of. Not only did I run
into software of high quality but also a community of people how are kind,
highly respectful and very helpful to each other. I feel drawn to
participate and contribute in a peaceful and respectful way, but I am a bit
scared that my lack of expressing expressing my self more precisely in the
English language can break things and hurt feelings. So if my words may be
to direct or offend people, please let me know I can always be contacted
also of list. Having said these words I do my best to formulate my ideas as
clear as I can.
It appears to me that the real problem with relative urls is not on the
level of Pmwiki but on a lower level. That is, the URL rewrite sequences.
This rewrite sequence is like a well balanced act between Pmwiki and Apache
and it needs to be set up very careful to work. Often it takes quite some
time to get it right and patience is needed to grasp how this act is
performed. let alone to pinpoint what exactly is happening when things don't
work as expected.
It appears to me, implementing absolute urls in favor of the good practice
of relative urls in the core of Pmwiki is the wrong path to take try to
"fix" the encountered problems as described with clean URL's. It appears to
me it's just not the right level to address the issue and more troublesome,
it breaks other behavior which normally should work, in this case the https
use of Pmwiki.
at this moment I think the best path to go is to address the mentioned
issues at the level they come into existence, that is when setting up a
configuration which outputs "clean urls"
Rewriting urls is like a can of worms, once opened,....
Well you know the feeling :-)
A week ago I spend a whole day getting it working on my wikifarm. The main
thing was grasping what in detail is actually happening and that's not easy
cause it's actually a concept of two layers.
1) The actual rewriting.
2) Adapting url links in pages, that are going to the client in a way things
Without having a good grasp on how to perform both, you pretty much lost and
your worms too!
As it appears to me that it would be a good practice to give administrators
first a good layout of the actually concept and the two layers in it. First
layer one needs to work correctly, than layer two needs to be addressed.
Cause there many different setups, it's hard if not impossible to just give a
recipe, that will work for all. What I think will work in much better way is
giving a structured methods to get things working. Of course it's a good
idea to incorporate or embed all tips and tricks, cause this could be the
right place to suggest using absolute urls if all else fails. We can also
point out how to get this working for mixed http, https sites.
| 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 second this, appears as a good idea to get this right. And if it's a
Apache issue shouldn't it be reported to to Apache people to be fixed?
| 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.
One can always easily switch back to absolute with the one liner in
config.php or farm.php
| > 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, I understand that it's much more subtle. And I totally agree that the
first impression is very important, cause it's the whole system in a
nutshell. For me the first impression of Pmwiki was: This is *really* good
software. So I was also really surprised by the https issue. But at that
time I was already convinced, this is the software I was looking for, so no
harm done :-)
Now let's find a way to get _all_ the worm back into the can :-)
| Thanks for the excellent post!
Thanks for excellent explanation. It's a joy to communicate this way :-)
More information about the pmwiki-users