#45314 [NEW]: wddx_serialize_value does not handle unicode properly
From: mikx at mikx dot de
Operating system: Linux, Windows
PHP version: 5.2.6
PHP Bug Type: *Unicode Issues
Bug description: wddx_serialize_value does not handle unicode properly
Description:
wddx_serialize_value does not deal as expected with unicode characters in
PHP 5.2.x or PHP 5.3.x. The function worked differently in PHP 5.1.6.
When serializing a string or a more complex objects any unicode characters
get again utf8 encoded - instead of getting in as is.
Reproduce code:
---
a href=?utf8=%E9%A1%B5Demo/a (some chinese character)
hr
form method=get action=?
input type=text name=utf8
input type=submit
/form
hr
?php
if (isset($_GET[utf8])) {
echo $_GET[utf8].br;
echo utf8_encode($_GET[utf8]).br;
echo wddx_serialize_value($_GET[utf8]).br;
}
?
Expected result:
The demo code is a little script that outputs the given query parameter
utf8 in three way:
1. Directly as recieved
2. utf8_encoded
3. serialized via wddx_serialize_value
In = 5.1.6 the resulting WDDX contained the utf8 characters excatly as
given. In = 5.2.0 the string gets UTF8 encoded again, just as if you would
have valled utf8_encode on it.
Actual result:
--
While the new behavior might make sense for data going forward (although i
am not sure what the expected behavior by WDDX spec is) this breaks
backward compatibility with old data.
As we have millons of database rows in unicode WDDX data this is a huge
issue (at least to us).
Can you please clarify if this is a bug, the expected behavior going
forward and how to deal with backward compatibility issues (maybe an
additional parameter to control the behavior)?
This might be related to bug #41722
--
Edit bug report at http://bugs.php.net/?id=45314edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45314r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45314r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45314r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45314r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45314r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45314r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45314r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45314r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45314r=support
Expected behavior:http://bugs.php.net/fix.php?id=45314r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45314r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45314r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45314r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45314r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45314r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45314r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45314r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45314r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45314r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45314r=mysqlcfg
#35241 [Bgs-Opn]: wddx deserialization problems with utf-8 data
ID: 35241 User updated by: mikx at mikx dot de Reported By: mikx at mikx dot de -Status: Bogus +Status: Open Bug Type: WDDX related Operating System: Linux, Windows PHP Version: 5CVS-2005-11-16 (snap) New Comment: This bug is not bogus in my oppionion (re-opening). WDDX deserialize isn't able to properly decode a valid utf-8 encoded and marked WDDX packet coming from another source (or written with a plain utf-8 text editor if you want). If i am wrong and this is expected behavior please give me a link to the documentation saying that an implicit conversion to latin1 is expected behavior. And please explain why and i which version of PHP this behavior changed - in PHP 4.3.9 it is different. Previous Comments: [2005-11-17 17:45:24] mikx at mikx dot de Ilia, the data i have is already utf8 encoded inside the database. And as output 5 of 6 shows in my testcase even if i specify an utf-8 xml header on a valid utf-8 encoded packet wddx_deserialize automaticly decodes the data to latin1. This has nothing to do with wddx_serialize directly, but of course: double encoding something already in utf8 again would work if i only serialize and deserialize in php5. But it would produce a corrupted, double-utf-8-encoded wddx file not properly working with other wddx tools. Currently wddx_deserialize adds an utf8_decode on everything not cleary marked as being already latin1 - therefore wddx_deserialize has a bug since it is not capable of properly decoding a valid utf8 encoded WDDX packet to an UTF-8 string. Well, or at least it is nowhere documented properly how to influence the behavior of wddx_deserialize. [2005-11-17 16:49:09] [EMAIL PROTECTED] To handle UTF data you need to use utf8_encode() function on the data itself and add xml header identifying the data as being UTF8. [2005-11-16 16:07:59] mikx at mikx dot de Tried the snapshot for Windows you linked to (PHP Version 5.1.0RC5-dev). Result for the testcase is exactly the same as with 5.0.5. [2005-11-16 15:53:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-11-16 15:20:42] mikx at mikx dot de Description: It seems the behavior of wddx_deserialize is inconsistent or at least unpredictable based on the given documentation. Not only between PHP 4 and 5, also based on the given packet data. I am not sure if this is a bug or expected behavior. I am aware of bug #34928 - so please don't just treat this as bogus. The following script behaves as described on PHP 5.0.5 on Windows and 5.0.4 on Linux (currently i have no 5.0.5 Linux testcase available) and PHP 4.3.9 on Linux. At least the windows version is a complete default installation. Please clearify what wddx serialize and deserialize exactly do (encoding), why the documentation encourages to add an additional utf8_encode to non-ascii characters on serialize and how the entire process can be influenced (e.g. which configs get used). setlocale() and putenv(locale=xyz) have no effect. Currently wddx_serialize adds no character set information and keeps whatever you supply as a string inside the resulting wddx file. So if you send an extended character in ISO-8859-1 or UTF-8 it will be the same in the resulting wddx packet. The deserializer seems to always convert the packet to ISO-8859-1 unless you explicitly set information in the XML file that it is already ISO-8859-1 (even if there is UTF-8 content in it). If the documentation entry to always utf8_encode a string before sending it to serialize is correct, it would mean you would have to double encode an UTF-8 string. But that seems like a dirty workaround. From my perspective both wddx_serialize and wddx_deserialize should add/respect the information to the XML file and get an additional parameter to enforce an input or output encoding or overwrite the default behavior. Currently i try to deserialize wddx packets produced with PHP4 in PHP5. They are stored in a database, firstly in MySQL4 (latin1 encoded) and now migrated to MySQL5 (utf8 encoded). What is the proper way to handle that? utf8_encode the packet (producing a double encoded packet) before sending to wddx_deserialize (which implicitly adds a utf8_decode on that data) seems like an evil hack in a undocumented area. This seems like a common migration path to me, so please specifiy clearly what to expect and what to do. Reproduce code: --- ?php header(Content-type: text/html; charset=UTF-8); echo ISO
#35241 [Bgs]: wddx deserialization problems with utf-8 data
ID: 35241 User updated by: mikx at mikx dot de Reported By: mikx at mikx dot de Status: Bogus Bug Type: WDDX related Operating System: Linux, Windows PHP Version: 5CVS-2005-11-16 (snap) New Comment: Thanks for that info. But why does this mean it is not a bug? Is decoding to Latin1 expected behavior or just a side effect? Can the default encoding of libxml2 be influenced? Will this become a regression if PHP will ever properly use utf-8 anywhere in the engine? Previous Comments: [2005-11-28 17:55:12] [EMAIL PROTECTED] It's different because now we use libxml2 instead of the old expat. [2005-11-28 17:27:00] mikx at mikx dot de This bug is not bogus in my oppionion (re-opening). WDDX deserialize isn't able to properly decode a valid utf-8 encoded and marked WDDX packet coming from another source (or written with a plain utf-8 text editor if you want). If i am wrong and this is expected behavior please give me a link to the documentation saying that an implicit conversion to latin1 is expected behavior. And please explain why and i which version of PHP this behavior changed - in PHP 4.3.9 it is different. [2005-11-17 17:45:24] mikx at mikx dot de Ilia, the data i have is already utf8 encoded inside the database. And as output 5 of 6 shows in my testcase even if i specify an utf-8 xml header on a valid utf-8 encoded packet wddx_deserialize automaticly decodes the data to latin1. This has nothing to do with wddx_serialize directly, but of course: double encoding something already in utf8 again would work if i only serialize and deserialize in php5. But it would produce a corrupted, double-utf-8-encoded wddx file not properly working with other wddx tools. Currently wddx_deserialize adds an utf8_decode on everything not cleary marked as being already latin1 - therefore wddx_deserialize has a bug since it is not capable of properly decoding a valid utf8 encoded WDDX packet to an UTF-8 string. Well, or at least it is nowhere documented properly how to influence the behavior of wddx_deserialize. [2005-11-17 16:49:09] [EMAIL PROTECTED] To handle UTF data you need to use utf8_encode() function on the data itself and add xml header identifying the data as being UTF8. [2005-11-16 16:07:59] mikx at mikx dot de Tried the snapshot for Windows you linked to (PHP Version 5.1.0RC5-dev). Result for the testcase is exactly the same as with 5.0.5. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35241 -- Edit this bug report at http://bugs.php.net/?id=35241edit=1
#35241 [Bgs]: wddx deserialization problems with utf-8 data
ID: 35241 User updated by: mikx at mikx dot de Reported By: mikx at mikx dot de Status: Bogus Bug Type: WDDX related Operating System: Linux, Windows PHP Version: 5CVS-2005-11-16 (snap) New Comment: Ilia, the data i have is already utf8 encoded inside the database. And as output 5 of 6 shows in my testcase even if i specify an utf-8 xml header on a valid utf-8 encoded packet wddx_deserialize automaticly decodes the data to latin1. This has nothing to do with wddx_serialize directly, but of course: double encoding something already in utf8 again would work if i only serialize and deserialize in php5. But it would produce a corrupted, double-utf-8-encoded wddx file not properly working with other wddx tools. Currently wddx_deserialize adds an utf8_decode on everything not cleary marked as being already latin1 - therefore wddx_deserialize has a bug since it is not capable of properly decoding a valid utf8 encoded WDDX packet to an UTF-8 string. Well, or at least it is nowhere documented properly how to influence the behavior of wddx_deserialize. Previous Comments: [2005-11-17 16:49:09] [EMAIL PROTECTED] To handle UTF data you need to use utf8_encode() function on the data itself and add xml header identifying the data as being UTF8. [2005-11-16 16:07:59] mikx at mikx dot de Tried the snapshot for Windows you linked to (PHP Version 5.1.0RC5-dev). Result for the testcase is exactly the same as with 5.0.5. [2005-11-16 15:53:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-11-16 15:20:42] mikx at mikx dot de Description: It seems the behavior of wddx_deserialize is inconsistent or at least unpredictable based on the given documentation. Not only between PHP 4 and 5, also based on the given packet data. I am not sure if this is a bug or expected behavior. I am aware of bug #34928 - so please don't just treat this as bogus. The following script behaves as described on PHP 5.0.5 on Windows and 5.0.4 on Linux (currently i have no 5.0.5 Linux testcase available) and PHP 4.3.9 on Linux. At least the windows version is a complete default installation. Please clearify what wddx serialize and deserialize exactly do (encoding), why the documentation encourages to add an additional utf8_encode to non-ascii characters on serialize and how the entire process can be influenced (e.g. which configs get used). setlocale() and putenv(locale=xyz) have no effect. Currently wddx_serialize adds no character set information and keeps whatever you supply as a string inside the resulting wddx file. So if you send an extended character in ISO-8859-1 or UTF-8 it will be the same in the resulting wddx packet. The deserializer seems to always convert the packet to ISO-8859-1 unless you explicitly set information in the XML file that it is already ISO-8859-1 (even if there is UTF-8 content in it). If the documentation entry to always utf8_encode a string before sending it to serialize is correct, it would mean you would have to double encode an UTF-8 string. But that seems like a dirty workaround. From my perspective both wddx_serialize and wddx_deserialize should add/respect the information to the XML file and get an additional parameter to enforce an input or output encoding or overwrite the default behavior. Currently i try to deserialize wddx packets produced with PHP4 in PHP5. They are stored in a database, firstly in MySQL4 (latin1 encoded) and now migrated to MySQL5 (utf8 encoded). What is the proper way to handle that? utf8_encode the packet (producing a double encoded packet) before sending to wddx_deserialize (which implicitly adds a utf8_decode on that data) seems like an evil hack in a undocumented area. This seems like a common migration path to me, so please specifiy clearly what to expect and what to do. Reproduce code: --- ?php header(Content-type: text/html; charset=UTF-8); echo ISO-8859-1 specified, ISO-8859-1 databr; echo produces latin1 output [php5]br; echo produces ISO-8859-1 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\ISO-8859-1\?wddxPacket version='1.0'header/datastringabc-äöü/string/data/wddxPacket).hr; echo UTF-8 specified, ISO-8859-1 databr; echo non-ascii characters get stripped [php5]br; echo produces ISO-8859-1 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\UTF-8\?wddxPacket version='1.0'header/datastringabc-äöü/string/data/wddxPacket).hr;; echo Nothing specified, ISO-8859-1 databr; echo non-ascii characters get stripped [php5]br; echo
#35241 [NEW]: wddx deserialization problems with utf-8 data
From: mikx at mikx dot de Operating system: Linux, Windows PHP version: 5.0.5 PHP Bug Type: WDDX related Bug description: wddx deserialization problems with utf-8 data Description: It seems the behavior of wddx_deserialize is inconsistent or at least unpredictable based on the given documentation. Not only between PHP 4 and 5, also based on the given packet data. I am not sure if this is a bug or expected behavior. I am aware of bug #34928 - so please don't just treat this as bogus. The following script behaves as described on PHP 5.0.5 on Windows and 5.0.4 on Linux (currently i have no 5.0.5 Linux testcase available) and PHP 4.3.9 on Linux. At least the windows version is a complete default installation. Please clearify what wddx serialize and deserialize exactly do (encoding), why the documentation encourages to add an additional utf8_encode to non-ascii characters on serialize and how the entire process can be influenced (e.g. which configs get used). setlocale() and putenv(locale=xyz) have no effect. Currently wddx_serialize adds no character set information and keeps whatever you supply as a string inside the resulting wddx file. So if you send an extended character in ISO-8859-1 or UTF-8 it will be the same in the resulting wddx packet. The deserializer seems to always convert the packet to ISO-8859-1 unless you explicitly set information in the XML file that it is already ISO-8859-1 (even if there is UTF-8 content in it). If the documentation entry to always utf8_encode a string before sending it to serialize is correct, it would mean you would have to double encode an UTF-8 string. But that seems like a dirty workaround. From my perspective both wddx_serialize and wddx_deserialize should add/respect the information to the XML file and get an additional parameter to enforce an input or output encoding or overwrite the default behavior. Currently i try to deserialize wddx packets produced with PHP4 in PHP5. They are stored in a database, firstly in MySQL4 (latin1 encoded) and now migrated to MySQL5 (utf8 encoded). What is the proper way to handle that? utf8_encode the packet (producing a double encoded packet) before sending to wddx_deserialize (which implicitly adds a utf8_decode on that data) seems like an evil hack in a undocumented area. This seems like a common migration path to me, so please specifiy clearly what to expect and what to do. Reproduce code: --- ?php header(Content-type: text/html; charset=UTF-8); echo ISO-8859-1 specified, ISO-8859-1 databr; echo produces latin1 output [php5]br; echo produces ISO-8859-1 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\ISO-8859-1\?wddxPacket version='1.0'header/datastringabc-äöü/string/data/wddxPacket).hr; echo UTF-8 specified, ISO-8859-1 databr; echo non-ascii characters get stripped [php5]br; echo produces ISO-8859-1 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\UTF-8\?wddxPacket version='1.0'header/datastringabc-äöü/string/data/wddxPacket).hr;; echo Nothing specified, ISO-8859-1 databr; echo non-ascii characters get stripped [php5]br; echo produces ISO-8859-1 output [php4]br; echo wddx_deserialize(wddxPacket version='1.0'header/datastringabc-äöü/string/data/wddxPacket).hr;; echo ISO-8859-1 specified, UTF-8 databr; echo produces utf-8 output [php5]br; echo produces UTF-8 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\ISO-8859-1\?wddxPacket version='1.0'header/datastring.utf8_encode(abc-äöü)./string/data/wddxPacket).hr;; echo UTF-8 specified, UTF-8 databr; echo produces latin1 output [php5]br; echo produces UTF-8 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\UTF-8\?wddxPacket version='1.0'header/datastring.utf8_encode(abc-äöü)./string/data/wddxPacket).hr;; echo Nothing specified, UTF-8 databr; echo produces latin1 output [php5]br; echo produces UTF-8 output [php4]br; echo wddx_deserialize(wddxPacket version='1.0'header/datastring.utf8_encode(abc-äöü)./string/data/wddxPacket).hr;; ? -- Edit bug report at http://bugs.php.net/?id=35241edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35241r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35241r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35241r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35241r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35241r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35241r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35241r=needscript Try newer version: http://bugs.php.net/fix.php?id=35241r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35241r=support Expected behavior: http://bugs.php.net/fix.php?id=35241r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35241r
#35241 [Fbk-Opn]: wddx deserialization problems with utf-8 data
ID: 35241 User updated by: mikx at mikx dot de Reported By: mikx at mikx dot de -Status: Feedback +Status: Open Bug Type: WDDX related Operating System: Linux, Windows PHP Version: 5.0.5 New Comment: Tried the snapshot for Windows you linked to (PHP Version 5.1.0RC5-dev). Result for the testcase is exactly the same as with 5.0.5. Previous Comments: [2005-11-16 15:53:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-11-16 15:20:42] mikx at mikx dot de Description: It seems the behavior of wddx_deserialize is inconsistent or at least unpredictable based on the given documentation. Not only between PHP 4 and 5, also based on the given packet data. I am not sure if this is a bug or expected behavior. I am aware of bug #34928 - so please don't just treat this as bogus. The following script behaves as described on PHP 5.0.5 on Windows and 5.0.4 on Linux (currently i have no 5.0.5 Linux testcase available) and PHP 4.3.9 on Linux. At least the windows version is a complete default installation. Please clearify what wddx serialize and deserialize exactly do (encoding), why the documentation encourages to add an additional utf8_encode to non-ascii characters on serialize and how the entire process can be influenced (e.g. which configs get used). setlocale() and putenv(locale=xyz) have no effect. Currently wddx_serialize adds no character set information and keeps whatever you supply as a string inside the resulting wddx file. So if you send an extended character in ISO-8859-1 or UTF-8 it will be the same in the resulting wddx packet. The deserializer seems to always convert the packet to ISO-8859-1 unless you explicitly set information in the XML file that it is already ISO-8859-1 (even if there is UTF-8 content in it). If the documentation entry to always utf8_encode a string before sending it to serialize is correct, it would mean you would have to double encode an UTF-8 string. But that seems like a dirty workaround. From my perspective both wddx_serialize and wddx_deserialize should add/respect the information to the XML file and get an additional parameter to enforce an input or output encoding or overwrite the default behavior. Currently i try to deserialize wddx packets produced with PHP4 in PHP5. They are stored in a database, firstly in MySQL4 (latin1 encoded) and now migrated to MySQL5 (utf8 encoded). What is the proper way to handle that? utf8_encode the packet (producing a double encoded packet) before sending to wddx_deserialize (which implicitly adds a utf8_decode on that data) seems like an evil hack in a undocumented area. This seems like a common migration path to me, so please specifiy clearly what to expect and what to do. Reproduce code: --- ?php header(Content-type: text/html; charset=UTF-8); echo ISO-8859-1 specified, ISO-8859-1 databr; echo produces latin1 output [php5]br; echo produces ISO-8859-1 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\ISO-8859-1\?wddxPacket version='1.0'header/datastringabc-äöü/string/data/wddxPacket).hr; echo UTF-8 specified, ISO-8859-1 databr; echo non-ascii characters get stripped [php5]br; echo produces ISO-8859-1 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\UTF-8\?wddxPacket version='1.0'header/datastringabc-äöü/string/data/wddxPacket).hr;; echo Nothing specified, ISO-8859-1 databr; echo non-ascii characters get stripped [php5]br; echo produces ISO-8859-1 output [php4]br; echo wddx_deserialize(wddxPacket version='1.0'header/datastringabc-äöü/string/data/wddxPacket).hr;; echo ISO-8859-1 specified, UTF-8 databr; echo produces utf-8 output [php5]br; echo produces UTF-8 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\ISO-8859-1\?wddxPacket version='1.0'header/datastring.utf8_encode(abc-äöü)./string/data/wddxPacket).hr;; echo UTF-8 specified, UTF-8 databr; echo produces latin1 output [php5]br; echo produces UTF-8 output [php4]br; echo wddx_deserialize(?xml version=\1.0\ encoding=\UTF-8\?wddxPacket version='1.0'header/datastring.utf8_encode(abc-äöü)./string/data/wddxPacket).hr;; echo Nothing specified, UTF-8 databr; echo produces latin1 output [php5]br; echo produces UTF-8 output [php4]br; echo wddx_deserialize(wddxPacket version='1.0'header/datastring.utf8_encode(abc-äöü)./string/data/wddxPacket).hr;; ? -- Edit this bug report at http://bugs.php.net/?id=35241edit=1
#27777 [Opn]: basic authentication broken
ID: 2 User updated by: mikx at mikx dot de Reported By: mikx at mikx dot de Status: Open Bug Type: SOAP related Operating System: Windows XP Pro PHP Version: 5.0.0RC1 New Comment: At the momenten i have no non-wsdl demo case available, but it seems soap requests are working fine. If i remove the login/password from the options array i can only call __getFunctions() but none of the functions reported by it. I think that means i have got the wsdl file through uri authentication but the soap calls fail. After adding the login/password also to the options array i can call both __getFuntions() and testFunction() - a hello world testcase. Therefore adding login/password in the array seems to work like expected. Previous Comments: [2004-04-02 00:27:18] [EMAIL PROTECTED] Authentication should work for SOAP requests, but it is not working during requesting of WSDL file (not implemented). Do you have problem only with WSDL loading or with SOAP requests too? [2004-03-30 08:33:57] mikx at mikx dot de Description: When using basic authentication the soap client does not authenticate itself automaticly using the options array. You need to add the login and password in the uri. Reproduce code: --- _NOT working_ $client = new SoapClient(http://foo.com/bar.wsdl;, array( login = yourLogin, password = yourPassword)); _working_ $client = new SoapClient(http://yourLogin:[EMAIL PROTECTED]/bar.wsdl); Expected result: The SOAP client should take the login and password from the options array and automaticly authenticate itself. -- Edit this bug report at http://bugs.php.net/?id=2edit=1
#27777 [NEW]: basic authentication broken
From: mikx at mikx dot de Operating system: Windows XP Pro PHP version: 5.0.0RC1 PHP Bug Type: SOAP related Bug description: basic authentication broken Description: When using basic authentication the soap client does not authenticate itself automaticly using the options array. You need to add the login and password in the uri. Reproduce code: --- _NOT working_ $client = new SoapClient(http://foo.com/bar.wsdl;, array( login = yourLogin, password = yourPassword)); _working_ $client = new SoapClient(http://yourLogin:[EMAIL PROTECTED]/bar.wsdl); Expected result: The SOAP client should take the login and password from the options array and automaticly authenticate itself. -- Edit bug report at http://bugs.php.net/?id=2edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=2r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=2r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=2r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=2r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=2r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=2r=needscript Try newer version: http://bugs.php.net/fix.php?id=2r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=2r=support Expected behavior: http://bugs.php.net/fix.php?id=2r=notwrong Not enough info:http://bugs.php.net/fix.php?id=2r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=2r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=2r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=2r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=2r=dst IIS Stability: http://bugs.php.net/fix.php?id=2r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=2r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=2r=float
#24548 [NEW]: get_browser() does not return platform
From: mikx at mikx dot de
Operating system: Windows 2003 Server
PHP version: 4.3.2
PHP Bug Type: Unknown/Other Function
Bug description: get_browser() does not return platform
Description:
The object returned from get_browser() function does not contain the
platform information as described in the documentation and as usual in
prior versions.
It's more a missing feature than a bug, but it brings some old scripts
relying on this feature into trouble.
The browscap.ini is the latest official one from Gary Keith.
Reproduce code:
---
$browser = get_browser();
foreach ($browser as $name = $value) {
print b$name/b $value br /\n;
}
--
Edit bug report at http://bugs.php.net/?id=24548edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24548r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24548r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24548r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24548r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24548r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24548r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24548r=support
Expected behavior: http://bugs.php.net/fix.php?id=24548r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24548r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24548r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24548r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24548r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24548r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24548r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24548r=gnused
#24548 [Opn]: get_browser() does not return platform
ID: 24548
User updated by: mikx at mikx dot de
Reported By: mikx at mikx dot de
Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows 2003 Server
PHP Version: 4.3.2
New Comment:
Just figured out that get_browser() does not return a fixed set of
informations - the platform information is only given if resolved.
It can't resolve most versions of Internet Explorer 6, not sure if this
is a bug or a weakness of the browscap.ini.
Previous Comments:
[2003-07-08 16:20:15] mikx at mikx dot de
Description:
The object returned from get_browser() function does not contain the
platform information as described in the documentation and as usual in
prior versions.
It's more a missing feature than a bug, but it brings some old scripts
relying on this feature into trouble.
The browscap.ini is the latest official one from Gary Keith.
Reproduce code:
---
$browser = get_browser();
foreach ($browser as $name = $value) {
print b$name/b $value br /\n;
}
--
Edit this bug report at http://bugs.php.net/?id=24548edit=1
