I came across an issue whilst following https://github.com/php-runtime/psr-17#psr-7-and-psr-15-runtime to use Slim's psr-7 implementation.
At least when running with php-fpm + nginx, $_SERVER['HTTP_PORT'] is populated with a numeric string, eg 8080. https://github.com/Nyholm/psr7-server/blob/master/src/ServerRequestCreator.php#L279 passes that string through to a UriInterface, which with Sim's implementation results in "Uri port must be null or an integer between 1 and 65535 (inclusive)" (because it fails an is_integer check). Using nyholm/psr7 works though, as it casts the string value to an int.
I was going to raise this as an issue against slim/psr-7, but on reading the http-mesage spec it looks like withPort should accept null|int. I think the more correct fix is that ServerRequestCreator should ensure that it is indeed passing in an integer or null.
I came across an issue whilst following https://github.com/php-runtime/psr-17#psr-7-and-psr-15-runtime to use Slim's psr-7 implementation. At least when running with php-fpm + nginx,
$_SERVER['HTTP_PORT']is populated with a numeric string, eg8080. https://github.com/Nyholm/psr7-server/blob/master/src/ServerRequestCreator.php#L279 passes that string through to aUriInterface, which with Sim's implementation results in "Uri port must be null or an integer between 1 and 65535 (inclusive)" (because it fails an is_integer check). Using nyholm/psr7 works though, as it casts the string value to an int. I was going to raise this as an issue against slim/psr-7, but on reading the http-mesage spec it looks likewithPortshould acceptnull|int. I think the more correct fix is thatServerRequestCreatorshould ensure that it is indeed passing in an integer or null.