Bug #55814 [Bgs]: stream_socket_recvfrom() “randomly” returns false
Edit report at https://bugs.php.net/bug.php?id=55814edit=1 ID: 55814 User updated by:ivan dot enderlin at hoa-project dot net Reported by:ivan dot enderlin at hoa-project dot net Summary:stream_socket_recvfrom() ârandomlyâ returns false Status: Bogus Type: Bug Package:Streams related Operating System: Windows 7 PHP Version:Irrelevant Assigned To:mattficken Block user comment: N Private report: N New Comment: Hi Matt, I understand the âproblemâ and I understand perfectly what you're proposing to me. But I don't understand why stream_socket_recvfrom() is not blocking here. Reading a socket is always blocking, isn't it? I will change the behavior for Windows7 only and coming back with feedbacks. Thanks for your time. Previous Comments: [2011-10-14 23:37:55] mattfic...@php.net I can reproduce this behavior on Windows 7, but not Linux (both using php 5.3.8). The manual entry for stream_socket_recvfrom, isn't clear on this, but really it just reads whatever message may be in the stream buffer (if any). Typically its used with stream_select. This is asynchronous IO, so you can't assume the message will be there when you call stream_socket_recvfrom. Even on Linux, if you're going to a remote host (your example is a localhost), it may not work sometimes due to network traffic, number of connections, etc... Windows network scheduling has different behavior than Linux. Thats why this 'problem' occurred. Also, because of those differences, if you call usleep(1) to sleep for just a 1 ms before calling stream_socket_recvfrom, the message will get into the buffer (because you're putting your program to sleep so Windows can use that time to do other work). Also, if you do: stream_set_blocking($client, true); before stream_socket_recvfrom, you'll convert the $client stream to synchronous IO (whereas its asynchronous by default) and your example will work then. I recommend you do that, or rewrite your code to use synchronous functions like fread(). [2011-10-13 21:55:46] paj...@php.net Matt, please analyze that one. [2011-09-29 14:23:07] ivan dot enderlin at hoa-project dot net Description: Sometimes, on Windows7 with PHP5.3+, stream_socket_recvfrom() returns false (the documentation says that it always returns a string but the source code says the opposite, it can return false), and I have no idea why. It happens only on Windows7 a priori. Basically, I have a client and a server as bellow. Test script: --- Client.php ?php $client = stream_socket_client( 'tcp://127.0.0.1:9001', $errno, $errstr, 30, STREAM_CLIENT_CONNECT ); echo 'Received '; var_dump(stream_socket_recvfrom($client, 6)); Server.php ?php $server = stream_socket_server( 'tcp://127.0.0.1:9001', $errno, $errstr, STREAM_SERVER_BIND | STREAM_SERVER_LISTEN ); echo 'Up listenâ¦', \n; $client = stream_socket_accept($server); echo 'New connection', \n; stream_socket_sendto($client, 'foobar'); echo 'Sent âfoobarâ', \n; Expected result: Client.php Received: string(6) foobar Server.php Up listen⦠New connection Sent âfoobarâ Actual result: -- Client.php Sometimes: Received: string(6) foobar Sometimes: Received: bool(false) Server.php Up listen⦠New connection Sent âfoobarâ -- Edit this bug report at https://bugs.php.net/bug.php?id=55814edit=1
Bug #42290 [Asn-Csd]: mb_eregi_replace() is not case-insensitive with multibyte pattern
Edit report at https://bugs.php.net/bug.php?id=42290edit=1 ID: 42290 Updated by: hirok...@php.net Reported by:arysin at gmail dot com Summary:mb_eregi_replace() is not case-insensitive with multibyte pattern -Status: Assigned +Status: Closed Type: Bug Package:mbstring related Operating System: * PHP Version:5.2CVS-2007-08-14 Assigned To:hirokawa Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Prior to PHP 5.4.0, the case-insensitive match of Unicode except for LATIN-1 area was not supported by the bundled multibyte regex library (Oniguruma 4.7.2). The Oniguruma library was updated to the newest version (5.9.2) which fully supports the Unicode property. Previous Comments: [2011-10-15 08:55:55] hirok...@php.net Automatic comment from SVN on behalf of hirokawa Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318132 Log: updated bundled oniguruma regex library to 5.9.2. fixed bug #42290. [2010-10-13 01:29:36] gevorg dot ha at gmail dot com Hi, please find code snippet which shoes that it doesn't work: mb_internal_encoding(UTF-8); mb_regex_encoding(UTF-8); // Text contains three words with same letters, only with some uppercases. $hText = 'ÕÔ±Õ Ô±ÕÕÔ±ÕÔ¸ ÕÕ¡ÕµÕ¡Õ½Õ¿Õ¡Õ¶ Õ°Õ¡ÕµÕ¡Õ½Õ¿Õ¡Õ¶'; // None of these two is working and only the last word is being replaced. echo mb_eregi_replace ('Õ°Õ¡ÕµÕ¡Õ½Õ¿Õ¡Õ¶', 'strong\\0/strong', $hText).'br/'; echo mb_ereg_replace ('Õ°Õ¡ÕµÕ¡Õ½Õ¿Õ¡Õ¶', 'strong\\0/strong', $hText, 'msri').'br/'; Best, Gevorg [2010-08-28 03:20:07] hirok...@php.net Could you show me the detailed information such as, - code snippet which can reproduce the problem. - setting information of mbstring.* in php.ini - character encoding which you are using. - version/locale of your OS. [2010-08-27 16:36:18] bubalula at gmail dot com I tried also on another server with php version 5.2.11 and it does not work either. [2010-08-27 16:22:05] bubalula at gmail dot com I have the same problem in version 5.2.12. I don't know why this bug isn't taken seriously as it creates big problems for us working with non latin languages. 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 https://bugs.php.net/bug.php?id=42290 -- Edit this bug report at https://bugs.php.net/bug.php?id=42290edit=1
Req #44761 [Opn-Bgs]: DOM Large Files
Edit report at https://bugs.php.net/bug.php?id=44761edit=1 ID: 44761 Updated by: rricha...@php.net Reported by:xwisdom at yahoo dot com Summary:DOM Large Files -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Windows XP PHP Version:5.2.5 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2011-10-14 15:27:16] clicky at erebot dot net The DOM extension is meant explicitely to handle small XML files as it requires a copy of the file being processed and a large number of objects be kept in memory (this is also true for the SimpleXML extension which is based on the same underlying parsing library). If you need a faster alternative, I'd suggest you take a look at the XMLReader and XML Parser extensions (http://php.net/manual/en/book.xmlreader.php and http://php.net/manual/en/book.xml.php, respectively). XMLReader works by using a cursor-based parsing approach, while XML Parser uses a push-based approach. Here are some drawbacks though when using these extensions: - validation may not be possible (true XML Parser) - you can't use XPath to browse through the data (true for both extensions) Hope this helps. [2008-04-17 14:34:45] xwisdom at yahoo dot com Description: I think the (X)HTML DOM features are great but I would like for it to process the DOMDocument much faster. It appears that the HTML DOM features in php are not able to handle large html files (200k+). It's slow down when processing these files. I would like to request that the DOM processing objects be given a speed boost. The DOM that's present in the browsers are much faster at processing the element. If this can be done then it would be great! -- Edit this bug report at https://bugs.php.net/bug.php?id=44761edit=1
Bug #60027 [Opn-Bgs]: DOMDocument::schemaValidate
Edit report at https://bugs.php.net/bug.php?id=60027edit=1 ID: 60027 Updated by: rricha...@php.net Reported by:richard at organicdata dot co dot za Summary:DOMDocument::schemaValidate -Status: Open +Status: Bogus Type: Bug Package:DOM XML related Operating System: Centos 5.5 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. issue in libxml not PHP Previous Comments: [2011-10-14 09:16:23] richard at organicdata dot co dot za I'm becoming very concerned at the apparent lack of positive interest in this issue from the PHP team. Even the risk of inability to validate one of the world's most used document formats should in my opinion be high on PHPs agenda - and if it indeed is a problem under xmllint then the PHP team should be pushing xmllint to sort it out - as ultimately it is PHP that benefits from the functionality. Just to give you some sense in our case - this functionality is critical and not being able to use it or get it fixed may be enough to stop our use of PHP - which I would be really sad to see happen as it is a great language in many regards. I am more than willing to help in any way I can with samples, testing and so on however I am unable to fix this on my own. I do need someone from the team to engage constructively. If someone could please engage I would really appreciate it. thanks [2011-10-13 06:49:56] richard at organicdata dot co dot za Hello I'm afraid the below isn't clear for me. Please can we keep this simple. All I need is either: 1. to be told how to upload the tiny XML file that has been requested by cataphract at php.net; or 2. for Felipe to confirm that he has received the XML file and for him to provide it to the appropriate person; as I have sent it to his email address felipe at php.net could someone please help here so this can move forward and hopefully be resolved as soon as possible. thank you [2011-10-11 22:22:17] fel...@php.net The bug tracker just allows the following mime-types: application/x-txt, text/plain, text/x-diff, text/x-patch, text/x-c++, text/x-c, text/x-m4 and cannot be larger than 100k. [2011-10-11 18:54:42] richard at organicdata dot co dot za hi i'm out of ideas - I htmlencoded the example xml file and submitted and I get this message ERROR: Please do not SPAM our bug system. please can someone help me with ideas as to how to submit the xml file requested thanks! [2011-10-11 18:36:23] richard at organicdata dot co dot za ah since I see the last comment immediately I can only assume that the site doesn't handle pasted xml comments. Is there any way I can upload the example file or is there some other preferred method of file submission? thanks again 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 https://bugs.php.net/bug.php?id=60027 -- Edit this bug report at https://bugs.php.net/bug.php?id=60027edit=1
[PHP-BUG] Bug #60065 [NEW]: PHP installer does not recognize IIS FastCGI
From: Operating system: Windows 7 Professional PHP version: 5.3.8 Package: IIS related Bug Type: Bug Bug description:PHP installer does not recognize IIS FastCGI Description: Using manual page: http://www.php.net/install.windows.iis7, section To enable FastCGI support on Windows Vista SP1 and Windows 7, FastCGI was enabled in IIS. On attempting to install PHP and selecting IIS FastCGI on the Web Server Setup page, the following message was received: FastCGI is not installed on the current version of IIS. To enable FastCGI support go to Server Manager - Roles - Add Role Services - CGI. -- Edit bug report at https://bugs.php.net/bug.php?id=60065edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60065r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60065r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60065r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60065r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60065r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60065r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60065r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60065r=needscript Try newer version: https://bugs.php.net/fix.php?id=60065r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60065r=support Expected behavior: https://bugs.php.net/fix.php?id=60065r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60065r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60065r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60065r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60065r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60065r=dst IIS Stability: https://bugs.php.net/fix.php?id=60065r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60065r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60065r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60065r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60065r=mysqlcfg
Bug #60063 [Opn-Bgs]: bug in ltrim
Edit report at https://bugs.php.net/bug.php?id=60063edit=1 ID: 60063 Updated by: cataphr...@php.net Reported by:paul at around25 dot com Summary:bug in ltrim -Status: Open +Status: Bogus Type: Bug Package:*General Issues Operating System: Windows7 PHP Version:5.3SVN-2011-10-14 (SVN) Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Expected behavior. Previous Comments: [2011-10-14 14:56:14] earlchaos at gmail dot com ltrims second parameter is a list of chars. http://de3.php.net/manual/en/function.ltrim.php So as far as i can see, everyhing is fine here. cheers, Frank [2011-10-14 13:13:51] paul at around25 dot com Description: --- From manual page: http://www.php.net/function.ltrim#refsect1-function.ltrim-description --- Test script: --- echo ltrim('vlccballard', 'vlc'); Expected result: I'm expecting: cballard Actual result: -- I get as result: ballard -- Edit this bug report at https://bugs.php.net/bug.php?id=60063edit=1
Bug #60057 [Opn]: declare(encoding=UTF-8)==Unsupported encoding
Edit report at https://bugs.php.net/bug.php?id=60057edit=1 ID: 60057 Updated by: cataphr...@php.net Reported by:ryan at ryan-hanekamp dot com Summary:declare(encoding=UTF-8)==Unsupported encoding Status: Open Type: Bug Package:Unicode Engine related Operating System: Vista Home Premium SP2 PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Do you have mbstring enabled? Zend multibyte requires an extension that provide the multibyte functions: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_multibyte.c#multibyte_functions Previous Comments: [2011-10-13 17:07:48] ryan at ryan-hanekamp dot com Description: This is on the precompiled Windows QA NTS build 2011-Sep-15 14:27:38, running on Apache 2.2 as CGI. Multibyte support is now included by default, and my php.ini file includes zend.multibyte = On as a directive. Any script that includes the line declare(encoding=UTF-8); Triggers this warning: Warning: Unsupported encoding [UTF-8] in XXX on line YYY I have tried changing case and removing the dash. Presuming this derives from the same functionality as Multibyte Strings, this should be the correct name for this encoding: http://us2.php.net/manual/en/mbstring.supported-encodings.php Test script: --- declare(encoding=UTF-8); Expected result: Silent parsing of the script as UTF-8. Actual result: -- Warning: Unsupported encoding [UTF8] in H:\webserver\pd\wwwroot\qwertyuiop\index.php on line 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=60057edit=1
Bug #60057 [Opn-Fbk]: declare(encoding=UTF-8)==Unsupported encoding
Edit report at https://bugs.php.net/bug.php?id=60057edit=1 ID: 60057 Updated by: cataphr...@php.net Reported by:ryan at ryan-hanekamp dot com Summary:declare(encoding=UTF-8)==Unsupported encoding -Status: Open +Status: Feedback Type: Bug Package:Unicode Engine related Operating System: Vista Home Premium SP2 PHP Version:5.4.0beta1 Block user comment: N Private report: N Previous Comments: [2011-10-15 14:13:37] cataphr...@php.net Do you have mbstring enabled? Zend multibyte requires an extension that provide the multibyte functions: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_multibyte.c#multibyte_functions [2011-10-13 17:07:48] ryan at ryan-hanekamp dot com Description: This is on the precompiled Windows QA NTS build 2011-Sep-15 14:27:38, running on Apache 2.2 as CGI. Multibyte support is now included by default, and my php.ini file includes zend.multibyte = On as a directive. Any script that includes the line declare(encoding=UTF-8); Triggers this warning: Warning: Unsupported encoding [UTF-8] in XXX on line YYY I have tried changing case and removing the dash. Presuming this derives from the same functionality as Multibyte Strings, this should be the correct name for this encoding: http://us2.php.net/manual/en/mbstring.supported-encodings.php Test script: --- declare(encoding=UTF-8); Expected result: Silent parsing of the script as UTF-8. Actual result: -- Warning: Unsupported encoding [UTF8] in H:\webserver\pd\wwwroot\qwertyuiop\index.php on line 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=60057edit=1
[PHP-BUG] Bug #60066 [NEW]: PHP segfault when build against GeoIP 1.4.8
From: Operating system: GNU/Linux (Fedora 15) PHP version: 5.3.8 Package: geoip Bug Type: Bug Bug description:PHP segfault when build against GeoIP 1.4.8 Description: Reading the source code (of GeoIP) show that some GeoIPDBFileName are not defined, so this cause a segfault when trying to copy it to result. The trivial attached patch solves this issue. Test script: --- php -r 'var_dump(geoip_db_get_all_info());' Expected result: array(31) { [1]= array(3) { [available]= bool(true) [description]= string(21) GeoIP Country Edition [filename]= string(26) /usr/share/GeoIP/GeoIP.dat } ... Actual result: -- Segmentation fault (core dumped) -- Edit bug report at https://bugs.php.net/bug.php?id=60066edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60066r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60066r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60066r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60066r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60066r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60066r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60066r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60066r=needscript Try newer version: https://bugs.php.net/fix.php?id=60066r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60066r=support Expected behavior: https://bugs.php.net/fix.php?id=60066r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60066r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60066r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60066r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60066r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60066r=dst IIS Stability: https://bugs.php.net/fix.php?id=60066r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60066r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60066r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60066r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60066r=mysqlcfg
Bug #60066 [Opn-Asn]: PHP segfault when build against GeoIP 1.4.8
Edit report at https://bugs.php.net/bug.php?id=60066edit=1 ID: 60066 Updated by: fel...@php.net Reported by:fedora at famillecollet dot com Summary:PHP segfault when build against GeoIP 1.4.8 -Status: Open +Status: Assigned Type: Bug Package:geoip Operating System: GNU/Linux (Fedora 15) PHP Version:5.3.8 -Assigned To: +Assigned To:ohill Block user comment: N Private report: N New Comment: I've already fixed the crash in the svn months ago, see: http://svn.php.net/viewvc/pecl/geoip/trunk/geoip.c?r1=297236r2=311837 But no release has been done as far I know. Assigning bug to the maintainer. Previous Comments: [2011-10-15 14:43:30] fedora at famillecollet dot com Description: Reading the source code (of GeoIP) show that some GeoIPDBFileName are not defined, so this cause a segfault when trying to copy it to result. The trivial attached patch solves this issue. Test script: --- php -r 'var_dump(geoip_db_get_all_info());' Expected result: array(31) { [1]= array(3) { [available]= bool(true) [description]= string(21) GeoIP Country Edition [filename]= string(26) /usr/share/GeoIP/GeoIP.dat } ... Actual result: -- Segmentation fault (core dumped) -- Edit this bug report at https://bugs.php.net/bug.php?id=60066edit=1
Bug #60056 [Opn-Fbk]: Basic authorization crashes Windows CLI web server
Edit report at https://bugs.php.net/bug.php?id=60056edit=1 ID: 60056 Updated by: cataphr...@php.net Reported by:david dot gero at ec dot gc dot ca Summary:Basic authorization crashes Windows CLI web server -Status: Open +Status: Feedback Type: Bug Package:Built-in web server Operating System: Windows XP PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ This appears to have already been fixed. Previous Comments: [2011-10-13 20:33:30] david dot gero at ec dot gc dot ca Package: should be PHP built-in web server related [2011-10-13 20:10:14] david dot gero at ec dot gc dot ca The second error probably happens on lines 1766 and 1869 of sapi/cli/php_cli_server.c where you are using Z_STRVAL_PP(val) instead of just *val request.headers are strings, not Z_STRs Look at the other examples of zend_hash_find in php_cli_server.c [2011-10-13 19:13:29] david dot gero at ec dot gc dot ca The first error happens at line 805 of main/SAPI.c [2011-10-13 16:45:34] david dot gero at ec dot gc dot ca Sigh. Your bug system wouldn't let me upload the PHP file, saying it was text/x-php, which apparently isn't text. So here it is: ?php /*! \file basic-auth-test.php * \brief Test that basic authorization works even if web server doesn't do it */ function doauthreq() { header('WWW-Authenticate: Basic realm=Admin Area'); header((isset($_SERVER[SERVER_PROTOCOL]) ? $_SERVER[SERVER_PROTOCOL] : 'HTTP/1.0') . ' 401 Unauthorized'); ?!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title401 Authorization Required/title /headbody h1Authorization Required/h1 pThis server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required./p ?php if (isset($_SERVER['SERVER_SIGNATURE'])) echo 'hr', PHP_EOL, $_SERVER['SERVER_SIGNATURE'], PHP_EOL; ? /body/html ?php exit(); } if ((!isset($_SERVER[PHP_AUTH_USER])) || !isset($_SERVER[PHP_AUTH_PW])) { if (isset($_SERVER[REMOTE_USER]) ini_get(safe_mode)) { // web server did authentication, but safe_mode is hiding PHP_AUTH_PW $php_auth_user = preg_replace('/[^[:alnum:]\\xC0-\\xD6\\xD8-\\xF6\\xF8-\\xFF @.\'_-]+/', '', $_SERVER[REMOTE_USER]); $_SERVER[PHP_AUTH_USER] = $php_auth_user; $_SERVER[PHP_AUTH_PW] = 'testing'; } else { // web server not restricting access, request browser authentication doauthreq(); } } else if (!isset($_SERVER[REMOTE_USER])) { // web server not restricting access, browser has responded with authentication if (strcmp($_SERVER['PHP_AUTH_PW'], 'testing') != 0) doauthreq(); } ? html head titleBasic Authorization Test/title /head body bgcolor=white h1Basic Authorization Test/h1 pSuccess!br / You have been authorized as user: ?php echo $_SERVER[PHP_AUTH_USER]; ?/p /body /html [2011-10-13 16:37:50] david dot gero at ec dot gc dot ca Description: The attached Patch file is actually a PHP program that shows the problem. Command line was: php -S 127.0.0.1:8000 -t \html In a browser, goto http://localhost:8000/basic-auth-test.php 1. First error is that the browser's authorization request displays at 0 instead of at Admin Area, meaning the PHP CLI server is not sending the realm correctly. 2. Second error is that the PHP CLI server crashes when the browser sends the Authorization: Basic base64 userid:password Test script: --- Patch file below is test script Expected result: Expect the PHP CLI server not to crash, and to see the following at the browser: Success! You have been authorized as user: foo Actual result: -- Windows PHP CLI server crashes -- Edit this bug report at https://bugs.php.net/bug.php?id=60056edit=1
Bug #53818 [Csd-Asn]: Missing info in pg_get_notify function
Edit report at https://bugs.php.net/bug.php?id=53818edit=1 ID: 53818 User updated by:r dot i dot k at free dot fr Reported by:r dot i dot k at free dot fr Summary:Missing info in pg_get_notify function -Status: Closed +Status: Assigned Type: Bug Package:PostgreSQL related Operating System: Linux -PHP Version:5.2.17 +PHP Version:5.3.8 Assigned To:iliaa Block user comment: N Private report: N New Comment: The provided patch, 9 months ago, is still missing from 5.3 branch... It would be cool to have it pushed in official source code, since it still works (made for 5.2.17, applyable to 5.3.8), and give access to a feature appeared in PostgreSQL 14 months ago :((( Previous Comments: [2011-10-14 06:06:49] timosha at gmail dot com Please backport this patch to 5.3.x. :) [2011-01-27 17:02:36] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2011-01-22 19:32:25] r dot i dot k at free dot fr Description: Since Postgresql 9.0, event notifications fired by the NOTIFY sql command includes a payload (a 8000 bytes max piece of text). As of now, the PHP function pg_get_notify only retrieve the channel (name of the notification) and the backend pid. The attached patch improves this situation by adding the payload to the returned array of the pg_get_notify function, when the connected PG backend version is at least 9.0. Hope it helps... Test script: --- $dbconn = pg_connect(...) ; // To be completed pg_query($dbconn, LISTEN toto); pg_query($dbconn, NOTIFY toto, 'Hello world !'); $notify = pg_get_notify($dbconn, PGSQL_ASSOC) ; print_r($notify) ; Expected result: // Array(message = toto, pid = 12345, payload = Hello world !) Actual result: -- // Array(message = toto, pid = 12345) -- Edit this bug report at https://bugs.php.net/bug.php?id=53818edit=1
Bug #60064 [Opn-Asn]: constants SQLSRV_NULLABLE_YES, SQLSRV_NULLABLE_NO are reversed!
Edit report at https://bugs.php.net/bug.php?id=60064edit=1 ID: 60064 Updated by: fel...@php.net Reported by:android at mikedev dot com Summary:constants SQLSRV_NULLABLE_YES, SQLSRV_NULLABLE_NO are reversed! -Status: Open +Status: Assigned Type: Bug Package:sqlsrv Operating System: Windows 2003/2008 PHP Version:5.3.8 -Assigned To: +Assigned To:jguerin Block user comment: N Private report: N Previous Comments: [2011-10-14 15:40:44] android at mikedev dot com Description: --- From manual page: http://www.php.net/function.sqlsrv-field-metadata#refsect1-function.sqlsrv-field-metadata-returnvalues --- constants SQLSRV_NULLABLE_YES, SQLSRV_NULLABLE_NO are actually reversed! in my database, I set a field that is 'NOT NULL', sqlsrv_field_metadata() reports it is SQLSRV_NULLABLE_YES and vice versa for the SQLSRV_NULLABLE_NO. Test script: --- // open database and make connection, etc. // select * from mytable // etc. foreach( sqlsrv_field_metadata($stmt) as $fieldMetadata ) { print($fieldMetadata['Name'] . is ); if ( $fieldMetadata['Nullable'] === SQLSRV_NULLABLE_YES ) print(NULLABLE_YES\n); else if ( $fieldMetadata['Nullable'] === SQLSRV_NULLABLE_NO ) print(NULLABLE_NO\n); else print(NULLABLE_UNKNOWN\n); } Expected result: field1 is NULLABLE_YES field2 is NULLABLE_NO field3 is NULLABLE_NO Actual result: -- field1 is NULLABLE_NO field2 is NULLABLE_YES field3 is NULLABLE_YES -- Edit this bug report at https://bugs.php.net/bug.php?id=60064edit=1
[PHP-BUG] Bug #60067 [NEW]: Strange Recursive/interation
From: Operating system: Linux CGI/FastCGI PHP version: 5.3.8 Package: Variables related Bug Type: Bug Bug description:Strange Recursive/interation Description: I wrote an OOP PHP class to interact with an Shipping estimate API. I setup a logging system to help log track any issues during testing. The goal was to have this logging system remove certain index keys for both 'objects' and 'arrays' in a recursive manor. I believe that the passed-reference (variable using with an ampersand or what I call a 'live link') is being 'pushed' up. When I check the logged xml (in the example) it often read 'omitted'. The variable was being changed even though the original call to function wasn't done using a passed-reference. The function would work correctly with the corrected code or the log_xml calls completed first. Maybe using $v is what broke the pass reference and it was just a 'copy' after that. Test script: --- Code Sample Here http://pastebin.com/GcZMkD6B -- Edit bug report at https://bugs.php.net/bug.php?id=60067edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60067r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60067r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60067r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60067r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60067r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60067r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60067r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60067r=needscript Try newer version: https://bugs.php.net/fix.php?id=60067r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60067r=support Expected behavior: https://bugs.php.net/fix.php?id=60067r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60067r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60067r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60067r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60067r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60067r=dst IIS Stability: https://bugs.php.net/fix.php?id=60067r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60067r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60067r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60067r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60067r=mysqlcfg
Req #53399 [Opn]: Add E_STRICT when defining a required funcparameter after an optional parameter
Edit report at https://bugs.php.net/bug.php?id=53399edit=1 ID: 53399 Updated by: s...@php.net Reported by:jbafford at zort dot net Summary:Add E_STRICT when defining a required funcparameter after an optional parameter Status: Open Type: Feature/Change Request Package:Scripting Engine problem PHP Version:* Block user comment: N Private report: N New Comment: I think the idea is good, however the patch seems too complicated. I do not think we need additional flag and not sure why would we need additional pass through arguments to do it - if we say everything after certain arg is optional, then we already know how to do it, we have settings for that in args structure. And we can detect this stuation immediately when we parse the arguments on compile. Previous Comments: [2010-11-24 16:25:43] jbafford at zort dot net Description: PHP does not emit a warning of any kind when defining a function with a required parameter after an optional parameter. For example: function foo($optional = 1, $required) {} It doesn't make sense to define a required parameter after an optional one, since that effectively makes all preceding optional parameters required. Since this is an error that can produce bugs and other warnings if one is not careful (calling the above function with less than two parameters will cause warnings to be emitted for the missing $required parameter), PHP should emit a warning of some kind when functions like this are defined. The attached patch includes the following changes: * add an E_STRICT warning when such a function is defined. (The warning will only appear when E_STRICT is included in the php.ini, since it happens at script compile time, before error_reporting can be called.) * add Zend/tests/func_optarg1.phpt and Zend/tests/func_optarg2.phpt to test for the presence and absence of the warning * Fixes Zend/tests/call_user_func_005.phpt, which fails with the warning added. -- Edit this bug report at https://bugs.php.net/bug.php?id=53399edit=1
Bug #55754 [Opn-Csd]: Only variables should be passed by reference for ZEND_SEND_PREFER_REF params
Edit report at https://bugs.php.net/bug.php?id=55754edit=1 ID: 55754 Updated by: s...@php.net Reported by:dk at uw dot no Summary:Only variables should be passed by reference for ZEND_SEND_PREFER_REF params -Status: Open +Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.3.8 -Assigned To: +Assigned To:stas Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-10-16 00:34:01] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318137 Log: Bug #55754 - Only variables should be passed by reference for ZEND_SEND_PREFER_REF params [2011-09-21 12:46:04] dk at uw dot no Description: Built-in functions where a parameter is defined with ZEND_SEND_PREFER_REF raises a Strict Standards warning if an expression is passed as the argument. The PREFER part signals the preference of passing by reference, but if the argument is not a variable, it should behave as if the parameter was defined with ZEND_SEND_BY_VAL and keep quiet, just as for regular ZEND_SEND_BY_VAL parameters. Test script: --- ?php error_reporting(32767); current($arr = array(0 = a)); /* Strict Standards: ... */ current(array(0 = a)); current($arr); ? Actual result: -- Strict Standards: Only variables should be passed by reference in filename on line 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=55754edit=1
Bug #60056 [Fbk]: Basic authorization crashes Windows CLI web server
Edit report at https://bugs.php.net/bug.php?id=60056edit=1 ID: 60056 Updated by: larue...@php.net Reported by:david dot gero at ec dot gc dot ca Summary:Basic authorization crashes Windows CLI web server Status: Feedback Type: Bug Package:Built-in web server Operating System: Windows XP PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: see #55755, fixed already, thanks Previous Comments: [2011-10-15 15:54:45] cataphr...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ This appears to have already been fixed. [2011-10-13 20:33:30] david dot gero at ec dot gc dot ca Package: should be PHP built-in web server related [2011-10-13 20:10:14] david dot gero at ec dot gc dot ca The second error probably happens on lines 1766 and 1869 of sapi/cli/php_cli_server.c where you are using Z_STRVAL_PP(val) instead of just *val request.headers are strings, not Z_STRs Look at the other examples of zend_hash_find in php_cli_server.c [2011-10-13 19:13:29] david dot gero at ec dot gc dot ca The first error happens at line 805 of main/SAPI.c [2011-10-13 16:45:34] david dot gero at ec dot gc dot ca Sigh. Your bug system wouldn't let me upload the PHP file, saying it was text/x-php, which apparently isn't text. So here it is: ?php /*! \file basic-auth-test.php * \brief Test that basic authorization works even if web server doesn't do it */ function doauthreq() { header('WWW-Authenticate: Basic realm=Admin Area'); header((isset($_SERVER[SERVER_PROTOCOL]) ? $_SERVER[SERVER_PROTOCOL] : 'HTTP/1.0') . ' 401 Unauthorized'); ?!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title401 Authorization Required/title /headbody h1Authorization Required/h1 pThis server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required./p ?php if (isset($_SERVER['SERVER_SIGNATURE'])) echo 'hr', PHP_EOL, $_SERVER['SERVER_SIGNATURE'], PHP_EOL; ? /body/html ?php exit(); } if ((!isset($_SERVER[PHP_AUTH_USER])) || !isset($_SERVER[PHP_AUTH_PW])) { if (isset($_SERVER[REMOTE_USER]) ini_get(safe_mode)) { // web server did authentication, but safe_mode is hiding PHP_AUTH_PW $php_auth_user = preg_replace('/[^[:alnum:]\\xC0-\\xD6\\xD8-\\xF6\\xF8-\\xFF @.\'_-]+/', '', $_SERVER[REMOTE_USER]); $_SERVER[PHP_AUTH_USER] = $php_auth_user; $_SERVER[PHP_AUTH_PW] = 'testing'; } else { // web server not restricting access, request browser authentication doauthreq(); } } else if (!isset($_SERVER[REMOTE_USER])) { // web server not restricting access, browser has responded with authentication if (strcmp($_SERVER['PHP_AUTH_PW'], 'testing') != 0) doauthreq(); } ? html head titleBasic Authorization Test/title /head body bgcolor=white h1Basic Authorization Test/h1 pSuccess!br / You have been authorized as user: ?php echo $_SERVER[PHP_AUTH_USER]; ?/p /body /html 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 https://bugs.php.net/bug.php?id=60056 -- Edit this bug report at https://bugs.php.net/bug.php?id=60056edit=1
Bug #60067 [Com]: Strange Recursive/interation
Edit report at https://bugs.php.net/bug.php?id=60067edit=1 ID: 60067 Comment by: anonymous at anonymous dot anonymous Reported by:bigorangemachine at hotmail dot com Summary:Strange Recursive/interation Status: Open Type: Bug Package:Variables related Operating System: Linux CGI/FastCGI PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Needs an SSCCE: http://sscce.org/ Previous Comments: [2011-10-15 19:39:27] bigorangemachine at hotmail dot com Description: I wrote an OOP PHP class to interact with an Shipping estimate API. I setup a logging system to help log track any issues during testing. The goal was to have this logging system remove certain index keys for both 'objects' and 'arrays' in a recursive manor. I believe that the passed-reference (variable using with an ampersand or what I call a 'live link') is being 'pushed' up. When I check the logged xml (in the example) it often read 'omitted'. The variable was being changed even though the original call to function wasn't done using a passed-reference. The function would work correctly with the corrected code or the log_xml calls completed first. Maybe using $v is what broke the pass reference and it was just a 'copy' after that. Test script: --- Code Sample Here http://pastebin.com/GcZMkD6B -- Edit this bug report at https://bugs.php.net/bug.php?id=60067edit=1
Bug #60067 [Com]: Strange Recursive/interation
Edit report at https://bugs.php.net/bug.php?id=60067edit=1 ID: 60067 Comment by: bigorangemachine at hotmail dot com Reported by:bigorangemachine at hotmail dot com Summary:Strange Recursive/interation Status: Open Type: Bug Package:Variables related Operating System: Linux CGI/FastCGI PHP Version:5.3.8 Block user comment: N Private report: N New Comment: FROM (corrected): if(@in_array($k,$exclude_keys,true)){ if($_type=='object'){ if(!basic_check($omit_str)){unset($obj-{$k});} else{$obj-{$k}=$omit_str;} }else if($_type=='array'){ if(!basic_check($omit_str)){unset($obj[$k]);} else{$obj[$k]=$omit_str;} } }else{ if(gettype($v)=='object' ($v instanceof Traversable)){// log_clean($obj-{$k},$exclude_keys,$omit_str);} else if(gettype($v)=='array'){ log_clean($obj[$k],$exclude_keys,$omit_str);} } TO (shortened): if(@in_array($k,$exclude_keys,true)){ if(!basic_check($omit_str)){unset($v);} else{$v=$omit_str;} }else{ log_clean($v,$exclude_keys,$omit_str); } I changed using $obj[$k] ( and $obj-{$k} [sorry for the syntax error]) to just using $v in the function log_clean(). This is my first bug report. Sorry if I don't have the format correct. Previous Comments: [2011-10-16 01:15:57] anonymous at anonymous dot anonymous Needs an SSCCE: http://sscce.org/ [2011-10-15 19:39:27] bigorangemachine at hotmail dot com Description: I wrote an OOP PHP class to interact with an Shipping estimate API. I setup a logging system to help log track any issues during testing. The goal was to have this logging system remove certain index keys for both 'objects' and 'arrays' in a recursive manor. I believe that the passed-reference (variable using with an ampersand or what I call a 'live link') is being 'pushed' up. When I check the logged xml (in the example) it often read 'omitted'. The variable was being changed even though the original call to function wasn't done using a passed-reference. The function would work correctly with the corrected code or the log_xml calls completed first. Maybe using $v is what broke the pass reference and it was just a 'copy' after that. Test script: --- Code Sample Here http://pastebin.com/GcZMkD6B -- Edit this bug report at https://bugs.php.net/bug.php?id=60067edit=1