ZF2-499: Safari, URI seems broken


In all the browsers I've been testing, Safari seems to be the only one experiencing this issue. The page will not load, returns a white page. Checking the system logs this is the full error I am receiving:

[Thu Aug 23 12:09:36.818671 2012] [:error] [pid 705:tid 140619267614464] [client fd35:4776:6804:1::1:55783] FastCGI: server "/tmp/admin-fpm80" stderr: PHP message: PHP Notice: Trying to get property of non-object in /usr/local/apache/vhosts/otwebsoft_admin/module/Application/src/Application/Controller/IndexController.php on line 35 [Thu Aug 23 12:12:45.418415 2012] [:error] [pid 706:tid 140619410290432] [client fd35:4776:6804:1::1:55832] FastCGI: server "/tmp/admin-fpm80" stderr: PHP message: PHP Fatal error: Uncaught exception 'Zend\Uri\Exception\InvalidUriPartException' with message 'Host "[fd35:4776:6804:2:2:]" is not valid or is not accepted by Zend\Uri\Http' in /usr/local/apache/vhosts/otwebsoft_admin/vendor/Zend/Uri/Uri.php:698 [Thu Aug 23 12:12:45.418738 2012] [:error] [pid 706:tid 140619410290432] [client fd35:4776:6804:1::1:55832] FastCGI: server "/tmp/admin-fpm80" stderr: Stack trace: [Thu Aug 23 12:12:45.418870 2012] [:error] [pid 706:tid 140619410290432] [client fd35:4776:6804:1::1:55832] FastCGI: server "/tmp/admin-fpm80" stderr: #0 /usr/local/apache/vhosts/otwebsoft_admin/vendor/Zend/Http/PhpEnvironment/Request.php(275): Zend\Uri\Uri->setHost('[fd35:4776:6804...') [Thu Aug 23 12:12:45.419576 2012] [:error] [pid 706:tid 140619410290432] [client fd35:4776:6804:1::1:55832] FastCGI: server "/tmp/admin-fpm80" stderr: #1 /usr/local/apache/vhosts/otwebsoft_admin/vendor/Zend/Http/PhpEnvironment/Request.php(85): Zend\Http\PhpEnvironment\Request->setServer(Object(Zend\Stdlib\Parameters)) [Thu Aug 23 12:12:45.419644 2012] [:error] [pid 706:tid 140619410290432] [client fd35:4776:6804:1::1:55832] FastCGI: server "/tmp/admin-fpm80" stderr: #2 /usr/local/apache/vhosts/otwebsoft_admin/vendor/Zend/Mvc/Service/RequestFactory.php(38): Zend\Http\PhpEnvironment\Request->__construct() [Thu Aug 23 12:12:45.420400 2012] [:error] [pid 706:tid 140619410290432] [client fd35:4776:6804:1::1:55832] FastCGI: server "/tmp/admin-fpm80" stderr: #3 [internal function]: Zend\Mvc\Service\RequestFactory->createService(Object(Zend\ServiceManager\ServiceManager), 'request', 'Request') [Thu Aug 23 12:12:45.420514 2012] [:error] [pid 706:tid 140619410290432] [client fd35:4776:6804:1::1:55832] FastCGI: server "/tmp/admin-fpm80" stderr: #4 /usr/local/apache/vhosts/otwebsoft_admin/vendor/Zend/ServiceManager/ServiceManager.php(684): call_user_func(Array, Object(Zend\ServiceManager\ServiceManager), '...

Not sure why this is happening to be honest. Testing browsers on Windows 7 are Firefox, IE, Chrome, Safari. If I access this in another browser, watching the logs absolutely no error is returned.

I should mention that I am currently using the latest version of Zend as of 08-23-2012 (looks like RC5 as of now).

Let me know if I can produce any other materials and I'll be happy to help.

IRC SN: Diemuzi


I guess that is something related with the last ":" in [fd35:4776:6804:2:2:]

I need to read the RFC for to know if is valid that

I should of added that the URL I'm accessing is [fd35:4776:6804:2:2::2]. Something I hadn't noticed the logs did not show.

As far as I see it, the Zend\Uri\Uri::setHost already gets the trunkated IP-Address as parameter as the Exception states "[fd35:4776:6804:2:2:]" as the problematic IP. This is the IP-That gets submitted as Parameter.

I've found a part in Zend\Http\PhpEnvironment\Request::setServer() where the port gets removed from the Server 'name' 'when $_SERVER['SERVER_NAME'] is not set'. Why this is happening only with your Safari-Browser I currently can not tell as my Safari does not behave like that. Which Safari-Version do you use? When I get that, I can dig into this further.

Safari Version: 5.1.7 (7534.57.2) Windows 7

Because I don't know if you know how IPv6 addresses work I'll just mention this. Keep in mind I'm accessing the IPv6 address of [fd35:4776:6804:2:2::2]. Notice there is no port number here, otherwise it would be written as [fd35:4776:6804:2:2::2]:80. The long version of this address would look like this [fd35:4776:6804:0002:0002:0000:0000:0002]. I have tried this as well but the results are the same.

As an additional test I setup an actual hostname and pointed it to this IP Address and Safari works. So that at least rules out any coding problems I may have caused for this to happen which I am unaware about.

I also tried an IPv4 address and it works too.

My only guess is that somewhere it's taking the : or :: in the IPv6 address and treating it like a port number, where-as it should not.

As stated before, I'm willing to help out as much as I can. Just hope I didn't push anyone's buttons by my IPv6 statement above.

Can you give us a var_dump of the $_SERVER-variable? I'm guessing, that some part of that array is missing and therefore the setServer-method does some magic that does not give the correct results. But to make that clear, we would need the var_dump. Actually it's just whether the key 'SERVER_NAME' is present or not.

Here are two vardumps so you have something to compare:



I found the cause of the issue.

The var_Dumps you provided showed the following lines:

Firefox: ["SERVER_NAME"]=> string(19) "" ["SERVER_ADDR"]=> string(21) "fd35:4776:6804:2:2::2" ["SERVER_PORT"]=> string(2) "80"

Safari: ["SERVER_NAME"]=> string(21) "[fd35:4776:6804:2:2:]" ["SERVER_ADDR"]=> string(21) "fd35:4776:6804:2:2::2" ["SERVER_PORT"]=> string(1) "2"

This shows, that the SERVER_NAME is already broken when sent from Safari to the Server. But that is the value that is used by the Request-Object to feed the host-name (which could be an IP) to the Uri-Object.

This seems to be a general PHP-Issue, not a ZF-Issue.

Sorry, but ZF can't know that that is already broken. :-(

aha! At least we found it =)

I was hesitant to even open this bug due to the possibility that it would be a browser issue. In your view, do you think this yields a PHP bug instead?

Thank you for taking the time to check this out =)

I guess that we must put a special case for Safari. [~matthew] Thoughts?

I think a special case where the user agent is known and we have something looking like an IPv6 address might make sense -- if it has happened once, it may happen again.

Fix with path

Credits to heiglandreas