reroute() uses SERVER_NAME as base instead

[lsafelix75]

Hi,

I encounter this strange behaviour of F3 lately. Both $f3->reroute('/en') and and $f3->reroute('en') have different behaviours. With $f3->reroute('/en'), the rerouted URL has the 'base url' change to SERVER_NAME defined in NGINX ini, whilst $f3->reroute('en') maintain the 'base url'. Is this an expected bahavior?

[pauljherring]

Which behaviour would you expect each to provide if performed at the following URLs?:

https://www.example.com
https://www.example.com/subdirectory
https://www.example.com/subdirectory/subdirectory

If you expect them (i.e. both with and without the leading /) to end up at the same place, please provide your reasoning...

Meanwhile, same question for the following HTML in any *.htm page at all of the above three URLS:

<a href="relative_page.htm">Relative</a>
<a href="/absolute_page.htm">Absolute</a>

[lsafelix75]

With the following route setting:

[routes]
GET @home: /en = \FFMVC\Controllers\Index->index
....
GET / = /en

and Nginx.conf:
server_name = xxx
....

I expect this behavior:

1. when user hits http://127.0.0.1/ , it should divert to http://127.0.0.1/en. Instead, the current 3.6 build diverts user to http://xxx/en
2. when user hits http://127.0.0.1/en, it is routed to http://127.0.0.1/en/User/Index/index. This is correct

The same applies to $f3->reroute().

Question is .. why Case 1 changes the URL base domain to "server_name"

[ikkez]

The call without a leading / is not recommended or even documented behaviour. If you would put a protocol there, like http://foo.com you can reroute to an external URI. Everything else might lead to unexpected results.

[lsafelix75]

I know without leading slash is not recommended. See my behaviour #1 explained above. F3 uses replace root url to server_name which may break if the server is behind a proxy server.

[ikkez]

It doesn't replace the root url.. the point is, that with leading / it treats your URI as local path, relative to your project.. everything else is treated as external URI and not touched.. so en would lead to a header Location: en which is technically wrong and might lead to unexpected browser behaviours.
Internal redirects however (/en) are changed to absolute URLs, see f3-factory/fatfree-core@6c22137
so it'll end in Location: http://myhostname.com:8080/base-path/en which is correct in terms of the RFC2616; § 14.30

So yes we should probably fix $url values that do not have a leading / and are not external URIs.

[ikkez]

@lsafelix75 so what to use instead of $f3->HOST? I think it's still so most reliable and expected behaviour. In your edge-case, where you actually want to stick on your IP-based host and not want to be redirected to the known active server name, your best option is to edit the HOST var accordingly after loading the framework.

$f3 = \Base::instance();
$f3->set('HOST', '127.0.0.1');

[Jiab77]

I've also got a weird issue but I won't consider it as a bug but it's related to this issue. While using the PHP embedded server to dev my project locally, I've used 0.0.0.0:port as listen interface and localhost:port on the browser side.

Everything was running smooth until the use of $f3->reroute('/404');... It changed localhost:port to 0.0.0.0:port on browser side and makes me loose the opened session.

Maybe I did something wrong so no need to open another issue. @ikkez is it a wanted behavior?

[ikkez]

That's no bug, it's a feature 😁 and if so, it perfectly fit into this issue here.

[Jiab77]

@ikkez Thanks for your reply, so no need to debug it's more on my side 👍

[lsafelix75]

@ikkez it still doesn't solve the problem. May be i set to another example with similar route setting as above:

[routes]
GET @home: /en = \FFMVC\Controllers\Index->index
....
GET / = /en

1. when user hits http://whatever.com/ , it should divert to http://whatever.com/en. Instead, the current 3.6.5 build diverts user to http://127.0.0.1/en (if using your idea of f3->set('HOST', '127.0.0.1'))

However, if i change the route setting to:

[routes]
GET @home: /en = \FFMVC\Controllers\Index->index
....
GET / = en

1. when user hits http://whatever.com/ , it is diverted to http://whatever.com/en. which is correct

It doesn't replace the root url.. the point is, that with leading / it treats your URI as local path, relative to your project.. everything else is treated as external URI and not touched.. so en would lead to a header Location: en which is technically wrong and might lead to unexpected browser behaviours.
Internal redirects however (/en) are changed to absolute URLs, see bcosca/fatfree-core@6c22137
so it'll end in Location: http://myhostname.com:8080/base-path/en which is correct in terms of the RFC2616; § 14.30

So yes we should probably fix $url values that do not have a leading / and are not external URIs.

Not sure how this will resolve my issue. With the following, basically, you are constructing a new absolute URL instead of relative URL from the base.

if ($url[0]=='/')
	$url=$this->hive['SCHEME'].'://'.
	    $this->hive['HOST'].$this->hive['BASE'].$url;

[lsafelix75]

i suggest you remove the following entirely. I am not sure what is the implication for other parts, by taking out this part, it is basically to construct a relative URL instead of an absolute URL if we do reroute()

if ($url[0]=='/')
	$url=$this->hive['SCHEME'].'://'.
	    $this->hive['HOST'].$this->hive['BASE'].$url;

[ikkez]

It is mandatory to build an absolute location url, the patch at f3-factory/fatfree-core@1e409a3 fixes this issue and the behaviour should be similar now (rerouting to /en or en. The problem is that your server host name is not set properly. No things to add here IMO.