Closed PascalTurbo closed 5 years ago
PROJECT_BASEURI
should also be configurable. Both depend on the same calculation. And both are source of problems during installation in some environments (see #30, #144, #147, #271, #361).
An other option would be to improve the calculation of PROJECT_BASEURI
and PROJECT_URI
. There are, as far as I know, 4 cases to consider. This are the 4 cases in the example of cal.php
:
domain redirection: baikal1.example.com -> …/htdocs/baikal1/
DOCUMENT_ROOT: …/htdocs/baikal1/
SCRIPT_FILENAME: …/htdocs/baikal1/cal.php
REQUEST_URI: baikal1.example.com/cal.php/…
domain redirection: baikal1.example.com -> …/htdocs/baikal1/
DOCUMENT_ROOT: …/htdocs/
SCRIPT_FILENAME: …/htdocs/baikal1/cal.php
REQUEST_URI: baikal1.example.com/cal.php/…
domain redirection: baikal1.example.com -> …/htdocs/baikal1/
DOCUMENT_ROOT: …/htdocs/baikal1/
SCRIPT_FILENAME: …/htdocs/baikal1/baikal2/cal.php
REQUEST_URI: baikal1.example.com/baikal2/cal.php/…
domain redirection: baikal1.example.com -> …/htdocs/baikal1/
DOCUMENT_ROOT: …/htdocs/
SCRIPT_FILENAME: …/htdocs/baikal1/baikal2/cal.php
REQUEST_URI: baikal1.example.com/baikal2/cal.php/…
@PascalTurbo: Due to the lack of details, I am not quite sure, if one of the cases fits to your problem.
I suggest the following update of Core/Frameworks/Flake/Framework.php
to fix this problem:
# Determine PROJECT_BASEURI
# in some environments $_SERVER["DOCUMENT_ROOT"] . PROJECT_BASEURI != $_SERVER["SCRIPT_FILENAME"]
# PROJECT_BASEURI has to be calculated using $_SERVER["SCRIPT_FILENAME"] and $_SERVER["SCRIPT_NAME"]
# finde start of shared postfix of $_SERVER["SCRIPT_FILENAME"] and $_SERVER["SCRIPT_NAME"]
$i = 1;
while ($i <= min(strlen($_SERVER["SCRIPT_FILENAME"]),strlen($_SERVER["SCRIPT_NAME"]))
&& substr($_SERVER["SCRIPT_FILENAME"], -$i, 1) == substr($_SERVER["SCRIPT_NAME"], -$i, 1)) {
$i++;
}
$sScript = substr($_SERVER["SCRIPT_FILENAME"], -($i-1), $i);
unset($i);
$sScript = substr($sScript,strpos($sScript,DIRECTORY_SEPARATOR)); # remove path segement stubs
$sScript = substr($_SERVER["REQUEST_URI"],0,strrpos($_SERVER["REQUEST_URI"],preg_replace("/index\.php$/","",$sScript))) . $sScript; # get folder of the script (using preg_replace to remove automatically added index.php or similar)
$sDirName = str_replace("\\", "/", dirname($sScript)); # fix windows backslashes
It is clear, that this causes an calculation overhead, which would be an advantage of the parameter configuration.
$sScript
is also used for calculation of PROJECT_URI
. But I don't know if it solves @PascalTurbo s problem.
Honestly i think it's important to try to not automatically detect anything if you have more complex needs. imho it's better to find a way to hardcode your exact paths. None of these variables are universally reliable.
My understanding is that you're looking for a way to support the idea that the proxy base url is different than the origin url. To properly support this, it's not enough to just set the relevant $_SERVER variables. Every XML response for example would have incorrect urls.
I'm closing this ticket because it's been a while since the last comment.
If this is indeed still an issue, feel free to comment here so we can continue discussing.
Hello, I have a similar problem (upgrading to 0.7.0 from 0.4.x): I have
Alias /cal/ /somedir/baikal/html/
in my httpd.conf (/somedir/baikal/ being outside the DocumentRoot, I don't want to put the entire Baikal tree in my DocumentRoot). The main page (https://mydom.ain/cal/) as well as the admin page (https://mydom.ain/cal/admin/) works, but /cal/dav.php complains:
Requested uri (/cal/dav.php) is out of base uri (/al/html/dav.php/)
It seems the base uri guessing logic is wrong, but only for dav.php, and not for index.php nor admin/index.php.
@Yenya have a look at #927. There you can find some workarounds. Also (if you have the time), I would be happy to hear what debug output you get when doing the steps outlined in #927.
@ByteHamster: added comment to #928
I have also found (trying to run Baikal inside container with reverse-proxy in front of it), that Baikal even adds <base href=...>
tag to its
<base href="127.0.0.1:8888">
into its output, which obviously does not work outside the container it is running in.
Having the PROJECT_URI (as seen from the outside world) configurable instead of incorrectly trying to guess it would help. Also, the <base>
tag should probably go away.
I fought a hard fight installing Baikal in my environment. After some investigation I found, that the base-url is calculated. This is a very nice behavior if you use baikal directly on a vhost - but unusable if you have a load balancer in front of it - so do I. There has been multiple problems:
I think it should be possible to configure the base url in the global configuration file. If it's not configured the current behaviour would fitt.