[PHP-BUG] Bug #61679 [NEW]: Error on non-standard HTTP methods
From: Operating system: Linux PHP version: 5.4.0 Package: Built-in web server Bug Type: Bug Bug description:Error on non-standard HTTP methods Description: The built in webserver bails out with an error on retrieval of a non-standard HTTP request method (e.g. PATCH). Test script: --- Run the PHP built in web server on PORT 8042 and use the following script to reproduce the error: $httpFilePointer = fopen( 'http://localhost:8042', 'r', false, stream_context_create( array( 'http' => array( 'method'=> 'PATCH', ), ) ) ); Expected result: A valid HTTP response, depending on the script run by the server. Actual result: -- The server logs to shell: [Mon Apr 9 15:45:35 2012] ::1:37726 Invalid request (Malformed HTTP request) The client complains about a malformed response: Warning: fopen(http://localhost:8042): failed to open stream: HTTP request failed! in ⦠-- Edit bug report at https://bugs.php.net/bug.php?id=61679&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61679&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61679&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61679&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61679&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61679&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61679&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61679&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61679&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61679&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61679&r=support Expected behavior: https://bugs.php.net/fix.php?id=61679&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61679&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61679&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61679&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61679&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61679&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61679&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61679&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61679&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61679&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61679&r=mysqlcfg
Bug #61679 [Asn->Opn]: Error on non-standard HTTP methods
Edit report at https://bugs.php.net/bug.php?id=61679&edit=1 ID: 61679 User updated by: t...@php.net Reported by: t...@php.net Summary:Error on non-standard HTTP methods -Status: Assigned +Status: Open Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.0 Assigned To:laruence Block user comment: N Private report: N New Comment: Just to make this clear: HTTP allows arbitrary method verbs to be used. Quoting the EBNF from RFC 2616, chapter 5.1.1: Method = "OPTIONS"; Section 9.2 | "GET"; Section 9.3 ⦠| extension-method extension-method = token Event if the server itself does not support a certain method, it should not crash, but send a 405 (Method Not Allowed) response. However, for the built in web server, it makes sense to let the executed script handle this and pipe arbitrary method verbs to it. Previous Comments: [2012-04-09 13:58:01] larue...@php.net hmm, I will try to fix it when I find what will apache does in such case :) ---- [2012-04-09 13:47:56] t...@php.net Description: The built in webserver bails out with an error on retrieval of a non-standard HTTP request method (e.g. PATCH). Test script: --- Run the PHP built in web server on PORT 8042 and use the following script to reproduce the error: $httpFilePointer = fopen( 'http://localhost:8042', 'r', false, stream_context_create( array( 'http' => array( 'method'=> 'PATCH', ), ) ) ); Expected result: A valid HTTP response, depending on the script run by the server. Actual result: -- The server logs to shell: [Mon Apr 9 15:45:35 2012] ::1:37726 Invalid request (Malformed HTTP request) The client complains about a malformed response: Warning: fopen(http://localhost:8042): failed to open stream: HTTP request failed! in ⦠-- Edit this bug report at https://bugs.php.net/bug.php?id=61679&edit=1
#48580 [NEW]: ArrayObject swallows properties (dump and reflection access)
From: t...@php.net
Operating system: Gentoo
PHP version: 5.2.9
PHP Bug Type: SPL related
Bug description: ArrayObject swallows properties (dump and reflection access)
Description:
Attributes defined in classes deriving from ArrayObject do not show up in
var_dump() and cannot be accessed via Reflection.
Note that this is fixed in 5.3 already.
Reproduce code:
---
class Bar extends ArrayObject
{
protected $foo = 23;
private $bar = 42;
}
var_dump( new Bar() );
Expected result:
object(Bar)#1 (0) {
["foo:protected"]=>
int(23)
["bar:private"]=>
int(42)
}
Actual result:
--
object(Bar)#1 (0) {
}
--
Edit bug report at http://bugs.php.net/?id=48580&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48580&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48580&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48580&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48580&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48580&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48580&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48580&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48580&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48580&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48580&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48580&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48580&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48580&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48580&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48580&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48580&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48580&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48580&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48580&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48580&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48580&r=mysqlcfg
#46624 [NEW]: Fetching results using PDO::FETCH_CLASS set attributes before calling ctor
From: [EMAIL PROTECTED]
Operating system:
PHP version: 5.2.6
PHP Bug Type: PDO related
Bug description: Fetching results using PDO::FETCH_CLASS set attributes before
calling ctor
Description:
If you set the PDO fetch mode to PDO::FETCH_CLASS and fetch all results
from a result set (aka processed statement), the constructor is called
after the properties of the newly created object are set.
This is incorrect from the OO point of view, since the ctor may provide
sensible default values for properties and prepare the object overall.
Therefore property manipulation should happen after the ctor was called.
Reproduce code:
---
$db = $this->getTrackbackDbConection();
$select = $db->query( 'SELECT ... ;' );
$select->setFetchMode( PDO::FETCH_CLASS, 'myCustomClass' );
$result = $select->fetchAll();
class myCustomClass
{
public $someProperty;
public function __construct()
{
$this->someProperty = 'default'
}
}
Expected result:
myCustomClass->$someProperty is overwritten by a value from the database.
Actual result:
--
myCustomClass->$someProperty is overwritten by 'default' since
__construct() is called after the properties have been set in PDO.
--
Edit bug report at http://bugs.php.net/?id=46624&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46624&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46624&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46624&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46624&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46624&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46624&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46624&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46624&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46624&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46624&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46624&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46624&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46624&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46624&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46624&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46624&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46624&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46624&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46624&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46624&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46624&r=mysqlcfg
#47937 [NEW]: headers_sent() reports 'true' after system() call in ob_start()
From: t...@php.net Operating system: FreeBSD, MacOSX PHP version: 5.2.9 PHP Bug Type: Output Control Bug description: headers_sent() reports 'true' after system() call in ob_start() Description: This is the php -v from one of the servers: PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: Apr 9 2009 03:31:34) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies This is another one (macosx): PHP 5.2.9 (cli) (built: Apr 2 2009 16:07:08) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with Xdebug v2.0.4, Copyright (c) 2002-2008, by Derick Rethans Right after my system() call, headers were send. This works differently in 5.2.6 and 5.2.8. I've scanned through UPDATING/CHANGELOG but couldn't find anything. I've disabled APC to make sure it's not connected. php -m: [PHP Modules] ctype date dom filter iconv libxml mbstring mcrypt mysqli pcre Reflection session SimpleXML sockets SPL standard tidy xml zlib Also reproduced with RC1 on 5.3: PHP 5.3.0RC1 (cli) (built: Apr 9 2009 15:45:09) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Reproduce code: --- http://bugs.php.net/?id=47937&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47937&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47937&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47937&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47937&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47937&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47937&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47937&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47937&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47937&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47937&r=support Expected behavior: http://bugs.php.net/fix.php?id=47937&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47937&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47937&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47937&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47937&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47937&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47937&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47937&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47937&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47937&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47937&r=mysqlcfg
Bug #55194 [Com]: PEAR doesn't honor the ext_dir configuration variable
Edit report at https://bugs.php.net/bug.php?id=55194&edit=1 ID: 55194 Comment by: t...@php.net Reported by:kalessin at kalessin dot fr Summary:PEAR doesn't honor the ext_dir configuration variable Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Sorry, somehow I f'd up the comment, what I meant to say was: Please report bugs for pear on http://pear.php.net/pear Also, your patch does literally nothing. !$foo and $foo === false are the same thing. file() returns false when the path is incorrect. Anyhow, please report over at PEAR. Previous Comments: [2011-07-13 07:48:11] t...@php.net It's bogus anyway. It's not supposed to suggest that. You'll have to set extension_dir in your php.ini so an extension is found and can be loaded. The complete path is never added to extension=foo.so. [2011-07-12 22:21:23] kalessin at kalessin dot fr Description: I'm using PEAR 1.9.0, but newer version are also affected. PEAR fails to open and parse an empty php.ini file because the return value of file() is not checked correctly (see attached patch). It's easy to end up with an empty php.ini file when you set the php_ini configuration variable to a custom location. The attached patch applies to SVN r313186 Best regards PS: It's not clear where this bug should be reported, the PEAR website doesn't seem to have the concept of bugs in PEAR itself but only in packages⦠Test script: --- #!/bin/sh php_ini=`mktemp` pear config-set php_ini $php_ini user pecl install mongo rm -f $php_ini Expected result: [..] install ok: channel://pecl.php.net/mongo-1.2.1 Extension mongo enabled in php.ini % Actual result: -- [...] install ok: channel://pecl.php.net/mongo-1.2.1 php.ini "/tmp/tmp.V6wU8jpMA4" could not be read You should add "extension=mongo.so" to php.ini % -- Edit this bug report at https://bugs.php.net/bug.php?id=55194&edit=1
