Bug #15423 Updated: HTTP::negotiateLanguage() severely bugged.

ID: 15423 Updated by: vigna@acm.org Reported By: vigna@acm.org Status: Assigned Bug Type: PEAR related Operating System: Linux Red Hat 7.2 PHP Version: 4.1.1 Assigned To: mj New Comment: Is it possible to get CVS access? It did that some time ago, but now I cannot find a pointer in the PEAR site. The problem with "_" is that Linux uses that for locales. But an HTTP language negotiation should IMHO return the HTTP language, not some system-specific counterpart. The user has just to do a strtr if necessary. Better fix it now than breaking other code later... Previous Comments: ------------------------------------------------------------------------ [2002-02-07 06:18:42] mj@php.net The first two problems have been fixed in CVS. I also think, that we can easily change the problem with the language code, but I would like to hear the opinion of the package maintainers. - Martin ------------------------------------------------------------------------ [2002-02-07 05:36:42] vigna@acm.org The code for HTTP::negotiateLanguage() is severely bugged. At line 76 of HTTP.php, $HTTP_ACCEPT_LANGUAGE is accessed without having been declarated global. Thus negotiation always happens on the empty string (a warning is generated). At line 102 $HTTP_SERVER_VARS['REMOTE_HOST'] is accessed without checking for existence of the key, causing a warning. The example stated in the documentation above the function uses "_" to separate language and country. The HTTP RFC uses "-". The regexp used to parse the header has neither. The default value ("en_US") suffers from the same problem--it does not respect the RFC. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=15423&edit=1