date:20111015

Bug #55814 [Bgs]: stream_socket_recvfrom() “randomly” returns false

2011-10-15 Thread ivan dot enderlin at hoa-project dot net

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

2011-10-15 Thread hirokawa

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

2011-10-15 Thread rrichards

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

2011-10-15 Thread rrichards

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

2011-10-15 Thread bcehprx at blueyonder dot co dot uk

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

2011-10-15 Thread cataphract

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

2011-10-15 Thread cataphract

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

2011-10-15 Thread cataphract

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

2011-10-15 Thread fedora at famillecollet dot com

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

2011-10-15 Thread felipe

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

2011-10-15 Thread cataphract

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

2011-10-15 Thread r dot i dot k at free dot fr

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!

2011-10-15 Thread felipe

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

2011-10-15 Thread bigorangemachine at hotmail dot com

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

2011-10-15 Thread stas

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

2011-10-15 Thread stas

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

2011-10-15 Thread laruence

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

2011-10-15 Thread anonymous at anonymous dot anonymous

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

2011-10-15 Thread bigorangemachine at hotmail dot com

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

Bug #55814 [Bgs]: stream_socket_recvfrom() “randomly” returns false

Bug #42290 [Asn-Csd]: mb_eregi_replace() is not case-insensitive with multibyte pattern

Req #44761 [Opn-Bgs]: DOM Large Files

Bug #60027 [Opn-Bgs]: DOMDocument::schemaValidate

[PHP-BUG] Bug #60065 [NEW]: PHP installer does not recognize IIS FastCGI

Bug #60063 [Opn-Bgs]: bug in ltrim

Bug #60057 [Opn]: declare(encoding=UTF-8)==Unsupported encoding

Bug #60057 [Opn-Fbk]: declare(encoding=UTF-8)==Unsupported encoding

[PHP-BUG] Bug #60066 [NEW]: PHP segfault when build against GeoIP 1.4.8

Bug #60066 [Opn-Asn]: PHP segfault when build against GeoIP 1.4.8

Bug #60056 [Opn-Fbk]: Basic authorization crashes Windows CLI web server

Bug #53818 [Csd-Asn]: Missing info in pg_get_notify function

Bug #60064 [Opn-Asn]: constants SQLSRV_NULLABLE_YES, SQLSRV_NULLABLE_NO are reversed!

[PHP-BUG] Bug #60067 [NEW]: Strange Recursive/interation

Req #53399 [Opn]: Add E_STRICT when defining a required funcparameter after an optional parameter

Bug #55754 [Opn-Csd]: Only variables should be passed by reference for ZEND_SEND_PREFER_REF params

Bug #60056 [Fbk]: Basic authorization crashes Windows CLI web server

Bug #60067 [Com]: Strange Recursive/interation

Bug #60067 [Com]: Strange Recursive/interation

19 matches

Site Navigation

Mail list logo

Footer information