Coverage increased (+0.001%) to 97.814% when pulling 77bd8c9 on lornajane:uri-port-defaults into 0618c56 on slimphp:3.x.

In a case that someone should have an application (intranet apps) running on a different port, I don't think this change would work. e.g. http://myintranet.net:3200

In a case that someone should have an application (intranet apps) running on a different port, I don't think this change would work. e.g. http://myintranet.net:3200

Actually, I think that this scenario would continue to work as the HTTP_HOST value includes the port number when it's non-standard.

i.e. when I run php -S 0.0.0.0:8888 -t public/, then $_SERVER['HTTP_HOST'] is set to localhost:8888 as that's the URL that I navigate to to get to the website. We have this code which then kicks in to extract the port number.

I think it's reasonable to default to port 80 if HTTP_HOST is set. We need to consider SSL though as that needs the port to be set to 443, so may be we need to check SERVER_PORT for 443 explicitly before setting the default to 80?

Hmm, this is a really good point. Because the default should be 443 or 80, depending on the protocol, but I'm not sure we always know the protocol of the incoming request, only what the local server is using. If I use https:// for my ngrok tunnel, I still don't get that (default 443) port number in the HTTP_HOST

For tunneled requests these could be derived from X-Forwarded-Port and X-Forwarded-Proto. Not sure if it is the best idea to trust them by default, nor if ngrok sets these. I do know that atleast Cloudflare sets them them when using SSL proxying.

I've looked it up. According to the spec, if the Host header exists and doesn't have a port, then it is the default for the protocol.

i.e. if the port is missing from Host header, we should check getScheme() and set 443 or 80 as appropriate.

At the risk of thickening the plot, we don't have scheme either. Reading the git history the X-Forwarded* fields were deliberately removed since they can't always be trusted and that's the only place I can see the scheme. Luckily @akrabat has a middleware that reads those headers and applies the correct scheme to the request object which helped part of my problem but not the port number part.

Yes, you’d still need rka-scheme-and-host-middleware (now renamed to proxy-detection-middleware) to pick up the scheme. That middleware should probably handle the port better too.

Further thinking about the Uri part, it might be enough to set $port to null when the host header exists.

This works perfectly for me (using the middleware as well) both locally with a custom port number and with the ngrok tunnel in front of it.

Thanks.