Issue Type: Bug Created: 2010-06-17T10:14:21.000+0000 Last Updated: 2010-07-12T11:18:19.000+0000 Status: Resolved Fix version(s): - 1.10.7 (28/Jul/10)
Reporter: Zijin Huang (zijin) Assignee: Thomas Weidner (thomas) Tags: - Zend_Locale
Related issues: Attachments:
Does Zend_Locale fully support PHP running on Windows IIS ISAPI mode?
"getenv(HTTP_ACCEPT_LANGUAGE)" returns null with php running on Windows IIS ISAPI mode which causes the following Exception:
Fatal error: Uncaught exception 'Zend_Locale_Exception' with message 'Autodetection of Locale has been failed!'
Would it be better if getenv() can fall back to using $_SERVER variables in case getenv is not available?
To reproduce, simply create a file with the following (include Zend/Locale or Autoloader first of course):
$locale = new Zend_Locale(Zend_Locale::BROWSER);
Posted by Thomas Weidner (thomas) on 2010-06-17T11:10:41.000+0000
Closing as non-issue
This exception just notes that the browser does not send an language header.
And that in your environment even the system's locale can not be found. This exception is only thrown when no locale can be retrieved, wether within the browser, nor the environment. And when additionally the default fallback locale has been erased manually.
So the generic problem is not ISAPI but that even php's setlocale() method does not return any value and that default has been erased manually.
Posted by Zijin Huang (zijin) on 2010-06-17T13:18:03.000+0000
My broswer is correctly sending the language header. I can confirm this as I was migrating the code from Linux server to a Windows server. Same test code works fine on Linux server (using the same browser).
Please note that I have "Zend_Locale::BROWSER" in the constructor ( $locale = new Zend_Locale(Zend_Locale::BROWSER); ) which means I only want to check for browser language setting, it should not fall back to environment language settings anyway. It's not related to setlocale or locale not set in the server/php environment.
The problem really comes down to the getBrowser() function in Locale.php on Windows IIS ISAPI mode where getenv('HTTP_ACCEPT_LANGUAGE') is called. getenv('HTTP_ACCEPT_LANGUAGE') function call returns null even when the correct header is sent. In fact, getenv() returns null for whatever server variables I try to get. However $_SERVER["HTTP_ACCEPT_LANGUAGE"] is available, so my question is whether getenv('HTTP_ACCEPT_LANGUAGE') can fallback to use $_SERVER["HTTP_ACCEPT_LANGUAGE"] just for Windows IIS ISAPI mode?
Looking at the PHP manual, it appear to suggest that in CGI mode, getenv will work: http://www.php.net/manual/en/function.getenv.php
Posted by Thomas Weidner (thomas) on 2010-07-04T11:37:15.000+0000
Tested with new information and agreed
Posted by Thomas Weidner (thomas) on 2010-07-04T11:39:44.000+0000
Fixed with r22529
Posted by Maciej Hołyszko (mh) on 2010-07-07T05:37:14.000+0000
I think this fix is not full - it should be wrapped with isset($_SERVER['HTTP_ACCEPT_LANGUAGE']) because this variable is not always available - for example when web crawlers visit our page. When we updated to r22529 of ZF 1.10 branch we now get a lot of PHP notices: *Undefined index HTTP_ACCEPT_LANGUAGE* at *Zend/Locale.php:430* from user-agents like "msnbot/2.0b (+http://search.msn.com/msnbot.htm)" or "Feedfetcher-Google; (+http://www.google.com/feedfetcher.html; ...)" or "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Posted by Thomas Weidner (thomas) on 2010-07-12T11:10:33.000+0000
Not reproduceable because there IS a check with isset()
Posted by Maciej Hołyszko (mh) on 2010-07-12T11:18:19.000+0000
Yes, it is there now indeed, because it was fixed in http://framework.zend.com/issues/browse/ZF-10114. Thank you. I guess I'd better create a separate issue next time instead of commenting already closed one.
Have you found an issue?
See the Overview section for more details.