#48885 [Com]: finfo returns mime type + charset when FILEINFO_MIME is used
ID: 48885
Comment by: matthew at zend dot com
Reported By: majkl578 at gmail dot com
Status: To be documented
Bug Type: Filesystem function related
Operating System: Linux Debian
PHP Version: 5.3.0
New Comment:
I beg to differ a bit here with the assertion that the change is not a
BC break.
Consider this: in versions prior to 5.3.0, one could do a match like
this:
$finfo = new finfo(FILEINFO_MIME);
$type = $finfo-file($filename);
if (!in_array($type, array('image/jpeg', 'image/jpg'))) {
echo Invalid image type.;
} else {
echo JPEG found.
}
Now, with 5.3.0, this changes; the same assertion no longer works. This
is in fact exactly an issue we had with Zend_Validate_File_MimeType when
testing against PHP 5.3.0 -- matching that worked in 5.2.x now no longer
works in 5.3.0. We have altered our library to handle the strings
returned by both versions, but that exactly disproves your point: if the
new behavior were BC, we wouldn't *need* to update our code.
I feel at the very least, the fact that the MIME type returned also
includes encoding information, and the format of this encoding
information, needs to be documented in the manual, and likely the
UPGRADING guide.
Previous Comments:
[2009-07-12 23:16:53] scott...@php.net
As Pierre has said already this is the way libmagic works and it
matches the RFC for mime type.
The charset on non text documents is also valid, even if it just says
binary.
So there isn't a BC break here unless you were using the mime type for
something else.
[2009-07-12 13:33:48] paj...@php.net
The fileinfo extension has been bundled in PHP (5.3 and later). The
development takes place only in PHP, not anymore in PECL.
Old releases may have issues or may not be compliant with the RFC. Like
it or not, that's a fact.
For the binary data, the charset will obviously be set to binary:
image/gif; charset=binary
It is a documentation, not a bug neither a BC break.
[2009-07-12 12:32:34] majkl578 at gmail dot com
Look:
I tested the code mentioned in bug report on php 5.2.10, i used a JPEG
image:
On php 5.3.0 returns 'image/jpeg; charset=binary'
On php 5.2.10 returns 'image/jpeg' only.
So, my question is: is it a bug or a feature in 5.3?
If it's a feature:
1. it is NOT backward compatible.
2. it does not have any meaning for files like images etc, only for
text files.
So?
[2009-07-11 22:45:11] paj...@php.net
pls update this example
[2009-07-11 21:15:18] majkl578 at gmail dot com
ok sorry for this.
but if it is correct, informations here:
http://php.net/manual/en/function.finfo-file.php are misleading (see
Example #1), because there is not mentioned anything about this, just
about mime type.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48885
--
Edit this bug report at http://bugs.php.net/?id=48885edit=1
#44793 [NEW]: ArrayObject does not report as Iterator
From: matthew at zend dot com
Operating system: Linux (Ubuntu)
PHP version: 5.2.5
PHP Bug Type: SPL related
Bug description: ArrayObject does not report as Iterator
Description:
ArrayObject extends ArrayAccess, which implements ArrayIterator and in
turn Iterator. However, when checking to see if a concrete instance of
ArrayObject implements Iterator, the return is false.
Reproduce code:
---
$o = new ArrayObject(array());
if ($o instanceof Iterator) {
echo Instance of Iterator;
} else {
echo Failed;
}
Expected result:
Instance of Iterator
Actual result:
--
Failed
--
Edit bug report at http://bugs.php.net/?id=44793edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44793r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44793r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44793r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44793r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44793r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44793r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44793r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44793r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44793r=support
Expected behavior:http://bugs.php.net/fix.php?id=44793r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44793r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44793r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44793r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44793r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44793r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44793r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44793r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44793r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44793r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44793r=mysqlcfg
#44793 [Bgs]: ArrayObject does not report as Iterator
ID: 44793
User updated by: matthew at zend dot com
Reported By: matthew at zend dot com
Status: Bogus
Bug Type: SPL related
Operating System: Linux (Ubuntu)
PHP Version: 5.2.5
New Comment:
This is a bug in SPL, which is bundled in PHP core; additionally, it
exposes a potential issue with how inheritence is resolved in the
language. Please re-open.
Previous Comments:
[2008-04-21 15:51:24] [EMAIL PROTECTED]
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.
class ArrayObject implements IteratorAggregate, Traversable,
ArrayAccess, Serializable, Countable.
Traversable is not the same as Iterator: Traversable allows an object
to be magically iterated by, i.e foreach, while Iterator explicitly
provides userland iteration interface through
next/valid/current/key/rewind.
[2008-04-21 12:52:27] matthew at zend dot com
Description:
ArrayObject extends ArrayAccess, which implements ArrayIterator and in
turn Iterator. However, when checking to see if a concrete instance of
ArrayObject implements Iterator, the return is false.
Reproduce code:
---
$o = new ArrayObject(array());
if ($o instanceof Iterator) {
echo Instance of Iterator;
} else {
echo Failed;
}
Expected result:
Instance of Iterator
Actual result:
--
Failed
--
Edit this bug report at http://bugs.php.net/?id=44793edit=1
#41270 [NEW]: session_start warnings caught by error handler produce fatals
From: matthew at zend dot com
Operating system: Linux
PHP version: 5.2.2
PHP Bug Type: Session related
Bug description: session_start warnings caught by error handler produce fatals
Description:
In http://bugs.php.net/41253, Ralph Schindler notes an issue with how
session startup errors due to unwritable session.save_path settings
perform. This issue was closed as 'bogus', but I feel that the reviewer did
not fully understand the situation. He commented, You're trying to throw
an exception when the engine is shutting down, so
you get a pretty much expected fatal error.
The engine is not shutting down at this point, however. As Ralph notes in
the original bug, under normal circumstances, if session.save_path is not
writable, PHP simply emits an E_WARNING, not an E_FATAL, and continues
execution.
In the example he provides, we get radically different behaviour when
using an error handler to trap the E_WARNING and throw it as an exception
-- basically, even if a try/catch block is used, the otherwise recoverable
error now becomes a fatal one.
Please re-examine the issue.
Reproduce code:
---
?
ini_set('session.save_path', '/var/log');
set_error_handler('save_handler', E_ALL);
try {
session_start();
} catch (Exception $e) {
echo $e-getMessage();
}
function save_handler($errno, $errmsg)
{
throw new Exception('Error caught and thrown as exception: ' .
$errmsg);
}
Expected result:
Error caught and thrown as exception: session_start():
open(/var/log/sess_3e97dad0fe4ce6f285e97593471f2c88, O_RDWR) failed:
Permission denied (13)
Actual result:
--
Error caught and thrown as exception: session_start():
open(/var/log/sess_3e97dad0fe4ce6f285e97593471f2c88, O_RDWR) failed:
Permission denied (13)
Fatal error: Exception thrown without a stack frame in Unknown on line
0
--
Edit bug report at http://bugs.php.net/?id=41270edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41270r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41270r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41270r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41270r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41270r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41270r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41270r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41270r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41270r=support
Expected behavior:http://bugs.php.net/fix.php?id=41270r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41270r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41270r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41270r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41270r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41270r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41270r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41270r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41270r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41270r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41270r=mysqlcfg
#41270 [Bgs-Opn]: session_start warnings caught by error handler produce fatals
ID: 41270
User updated by: matthew at zend dot com
Reported By: matthew at zend dot com
-Status: Bogus
+Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.2
New Comment:
Tony -- thanks for the explanation. I have one question, though: from
what you say, it sounds like the error is not being raised until script
shutdown -- i.e., only when the script is attempting to write the
session. However, that doesn't seem to be the case. If I modify the
reproduce script to add an echo statement after the try/catch block, or
even in the try block *after* the call to session_start, that echo is
never reached.
From observing that behaviour, it *appears* that the exception is being
thrown before script shutdown. What is the explanation behind that
behaviour?
Previous Comments:
[2007-05-03 18:35:14] [EMAIL PROTECTED]
Once again, in more details:
ext/session writes its data on shutdown (if one doesn't call
session_write_close() explicitly, but this is not the case).
When the extension tries to write the data, it suddenly discovers that
the path is wrong and fails, producing the error. This error is caught
and converted to an exception, which is thrown by the error handler. But
at this point the engine is partly down and there is no active script
(its execution has finished and the engine is shutting down), hence
there is nobody to catch the exception and there is no stack frame
(that's exactly what the message says).
This is similar to following case:
?php
class foo {
function __destruct() {
thrown new Exception(boo);
}
}
$foo = new Foo;
/* uncomment the line below and the object will be destroyed when there
is an active scope.
though it does not change the fact that an uncaught exception results
in a fatal error.
*/
//unset($foo);
?
You seem to be expecting the exception to vanish somewhere, but that's
clearly wrong.
[2007-05-03 18:08:10] matthew at zend dot com
Description:
In http://bugs.php.net/41253, Ralph Schindler notes an issue with how
session startup errors due to unwritable session.save_path settings
perform. This issue was closed as 'bogus', but I feel that the reviewer
did not fully understand the situation. He commented, You're trying to
throw an exception when the engine is shutting down, so
you get a pretty much expected fatal error.
The engine is not shutting down at this point, however. As Ralph notes
in the original bug, under normal circumstances, if session.save_path is
not writable, PHP simply emits an E_WARNING, not an E_FATAL, and
continues execution.
In the example he provides, we get radically different behaviour when
using an error handler to trap the E_WARNING and throw it as an
exception -- basically, even if a try/catch block is used, the otherwise
recoverable error now becomes a fatal one.
Please re-examine the issue.
Reproduce code:
---
?
ini_set('session.save_path', '/var/log');
set_error_handler('save_handler', E_ALL);
try {
session_start();
} catch (Exception $e) {
echo $e-getMessage();
}
function save_handler($errno, $errmsg)
{
throw new Exception('Error caught and thrown as exception: ' .
$errmsg);
}
Expected result:
Error caught and thrown as exception: session_start():
open(/var/log/sess_3e97dad0fe4ce6f285e97593471f2c88, O_RDWR) failed:
Permission denied (13)
Actual result:
--
Error caught and thrown as exception: session_start():
open(/var/log/sess_3e97dad0fe4ce6f285e97593471f2c88, O_RDWR) failed:
Permission denied (13)
Fatal error: Exception thrown without a stack frame in Unknown on line
0
--
Edit this bug report at http://bugs.php.net/?id=41270edit=1
#41270 [Opn-Csd]: session_start warnings caught by error handler produce fatals
ID: 41270
User updated by: matthew at zend dot com
Reported By: matthew at zend dot com
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.2
New Comment:
Never mind -- the statements *are* being echoed -- I just didn't see
them as they were in the same line as the exception message.
Thanks for the explanations, Tony.
Previous Comments:
[2007-05-03 18:47:57] matthew at zend dot com
Tony -- thanks for the explanation. I have one question, though: from
what you say, it sounds like the error is not being raised until script
shutdown -- i.e., only when the script is attempting to write the
session. However, that doesn't seem to be the case. If I modify the
reproduce script to add an echo statement after the try/catch block, or
even in the try block *after* the call to session_start, that echo is
never reached.
From observing that behaviour, it *appears* that the exception is being
thrown before script shutdown. What is the explanation behind that
behaviour?
[2007-05-03 18:35:14] [EMAIL PROTECTED]
Once again, in more details:
ext/session writes its data on shutdown (if one doesn't call
session_write_close() explicitly, but this is not the case).
When the extension tries to write the data, it suddenly discovers that
the path is wrong and fails, producing the error. This error is caught
and converted to an exception, which is thrown by the error handler. But
at this point the engine is partly down and there is no active script
(its execution has finished and the engine is shutting down), hence
there is nobody to catch the exception and there is no stack frame
(that's exactly what the message says).
This is similar to following case:
?php
class foo {
function __destruct() {
thrown new Exception(boo);
}
}
$foo = new Foo;
/* uncomment the line below and the object will be destroyed when there
is an active scope.
though it does not change the fact that an uncaught exception results
in a fatal error.
*/
//unset($foo);
?
You seem to be expecting the exception to vanish somewhere, but that's
clearly wrong.
[2007-05-03 18:08:10] matthew at zend dot com
Description:
In http://bugs.php.net/41253, Ralph Schindler notes an issue with how
session startup errors due to unwritable session.save_path settings
perform. This issue was closed as 'bogus', but I feel that the reviewer
did not fully understand the situation. He commented, You're trying to
throw an exception when the engine is shutting down, so
you get a pretty much expected fatal error.
The engine is not shutting down at this point, however. As Ralph notes
in the original bug, under normal circumstances, if session.save_path is
not writable, PHP simply emits an E_WARNING, not an E_FATAL, and
continues execution.
In the example he provides, we get radically different behaviour when
using an error handler to trap the E_WARNING and throw it as an
exception -- basically, even if a try/catch block is used, the otherwise
recoverable error now becomes a fatal one.
Please re-examine the issue.
Reproduce code:
---
?
ini_set('session.save_path', '/var/log');
set_error_handler('save_handler', E_ALL);
try {
session_start();
} catch (Exception $e) {
echo $e-getMessage();
}
function save_handler($errno, $errmsg)
{
throw new Exception('Error caught and thrown as exception: ' .
$errmsg);
}
Expected result:
Error caught and thrown as exception: session_start():
open(/var/log/sess_3e97dad0fe4ce6f285e97593471f2c88, O_RDWR) failed:
Permission denied (13)
Actual result:
--
Error caught and thrown as exception: session_start():
open(/var/log/sess_3e97dad0fe4ce6f285e97593471f2c88, O_RDWR) failed:
Permission denied (13)
Fatal error: Exception thrown without a stack frame in Unknown on line
0
--
Edit this bug report at http://bugs.php.net/?id=41270edit=1
#40036 [NEW]: empty() does not work correctly with ArrayObject when using ARRAY_AS_PROPS
From: matthew at zend dot com
Operating system: Debian GNU/Linux (unstable)
PHP version: 5.2.0
PHP Bug Type: SPL related
Bug description: empty() does not work correctly with ArrayObject when using
ARRAY_AS_PROPS
Description:
When using the ArrayObject::ARRAY_AS_PROPS flag with ArrayObject, empty()
does not work correctly on properties defined using either array notation
or object notation (and not previously declared in the object). null,
false, and empty strings do not return a true value from empty().
If ARRAY_AS_PROPS is not specified, empty() works fine.
Reproduce code:
---
class View extends ArrayObject
{
public function __construct(array $array = array())
{
parent::__construct($array, ArrayObject::ARRAY_AS_PROPS);
}
}
$view = new View();
$view-foo = false;
$view-bar = null;
$view-baz = '';
if (empty($view['foo']) || empty($view-foo)) {
echo View::foo empty\n;
}
if (empty($view['bar']) || empty($view-bar)) {
echo View::bar empty\n;
}
if (empty($view['baz']) || empty($view-baz)) {
echo View::baz empty\n;
}
Expected result:
View::foo empty
View::bar empty
View::baz empty
Actual result:
--
No output received.
--
Edit bug report at http://bugs.php.net/?id=40036edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40036r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40036r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40036r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40036r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40036r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40036r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40036r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40036r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40036r=support
Expected behavior:http://bugs.php.net/fix.php?id=40036r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40036r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40036r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40036r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40036r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40036r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40036r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40036r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40036r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40036r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40036r=mysqlcfg
#38992 [NEW]: ReflectionMethod::invoke() and ::invokeArgs() static method calls should match
From: matthew at zend dot com
Operating system: Debian SID on i686
PHP version: 5.1.6
PHP Bug Type: Feature/Change Request
Bug description: ReflectionMethod::invoke() and ::invokeArgs() static method
calls should match
Description:
ReflectionMethod::invoke() and ReflectionMethod::invokeArgs()
implementations currently do not support the same functionality.
Currently, ReflectionMethod::invoke() can be called using a string class
name as the first argument *if* the method is declared static. However,
ReflectionMethod::invokeArgs(), called the same way, raises a warning and
does not invoke the method:
Warning: ReflectionMethod::invokeArgs() expects parameter 1 to be
object, string given
Calling with a string class name is undocumented currently, but a useful
feature to have. I'd request that invokeArgs() be made to match the
current invoke() functionality, and the documentation updated to indicate
this usage.
Reproduce code:
---
?php
class MyClass
{
public static function doSomething()
{
echo Did it!\n;
}
}
$r = new ReflectionMethod('MyClass', 'doSomething');
$args = array();
$r-invoke('MyClass', array());
$r-invokeArgs('MyClass', $args);
Expected result:
Did it!
Did it!
Actual result:
--
Did it!
Warning: ReflectionMethod::invokeArgs() expects parameter 1 to be object,
string given in ... line 13
--
Edit bug report at http://bugs.php.net/?id=38992edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38992r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38992r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38992r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38992r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38992r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38992r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38992r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38992r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38992r=support
Expected behavior:http://bugs.php.net/fix.php?id=38992r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38992r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38992r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38992r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38992r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38992r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38992r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38992r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38992r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38992r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38992r=mysqlcfg
