Edit report at https://bugs.php.net/bug.php?id=65359&edit=1
ID: 65359
Updated by: yohgaki@php.net
Reported by: spam2 at rhsoft dot net
Summary: Unknown: Skipping numeric key 1 in Unknown on line 0
-Status: Assigned
+Status: Closed
Type: Bug
Package: Session related
PHP Version: 5.4.17
Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
php_serialize will be available from PHP 5.5.4.
http://git.php.net/?p=php-
src.git;a=commit;h=c51f77fe83cea3a48d89423863e6916b77628e47
Previous Comments:
------------------------------------------------------------------------
[2013-08-10 21:34:56] spam2 at rhsoft dot net
> We don't have a reliable REQUEST_URI or such available.
> We only have the version in $_SERVER which might be changed
> by the user
which is more realiable as "in unknown"
> A way to improve the error might be saving the place
> where a session is started, while that costs a tiny
> bit of memory and CPU
the cost is not measureable and does even not exist in theory
------------------------------------------------------------------------
[2013-08-10 21:14:44] johannes@php.net
We don't have a reliable REQUEST_URI or such available. We only have the version in $_SERVER
which might be changed by the user.
In shutdown we also have no idea of what might have been the "main" script - a SAPI can
execute multiple files in a row (as auto_[ap|pre]pend_file do), apache_filter is an example.
A way to improve the error might be saving the place where a session is started, while that costs a
tiny bit of memory and CPU.
------------------------------------------------------------------------
[2013-08-10 21:02:33] spam2 at rhsoft dot net
> This is not feasible option. If PHP should detect invalid
> session data assignment, PHP should monitor every writes to
> variable
WTF - nobody needs to monitor anything to know the script
which is called - the design flaw is that this information
well known as long the script is running is *thrown away*
before the last possible event triggering an error and over
years nobody spent a second to fix this
> Anyway, I may be able to add REQUEST_URI to the error.
> Do you want it?
that is what i request all the time
> It can be retrieved via custom error handler, though.
not a option in case of *600* vhosts
> Another feasible option for you is that define user
> error handler that ignores this error
another option would be fix PHP's internal error handler
that it shuts up in case it has nothing useful to say
------------------------------------------------------------------------
[2013-08-10 20:50:36] yohgaki@php.net
> so again: we do not need a *incompatible* new session handler, we need proper
error-reporting and "in unknown" is always a *major bug* and design flaw
This is not feasible option. If PHP should detect invalid session data
assignment, PHP should monitor every writes to variable, not only $_SESSION
array, during execution only for "register_globals" limited serialize handler.
There is no such API in PHP. If we made it, it slows down PHP and nobody is
willing to do. (Technically, Zend engine provides handler for assignment. By
using the API, anyone can make a module that detects invalid writes to
$_SESSION)
It seems current documentation does not state that users are not able to save
numeric index session vars (and other special chars). However, older documents
explicitly states numeric session vars are prohibited/unsupported. It's our
document bug, but this is the way it supposed to work.
Therefore, correct way of fixing this "*major bug* and design flaw" is
introducing new serialize handler that is *not* bonded to register_globals.
Anyway, I may be able to add REQUEST_URI to the error. Do you want it? It can be
retrieved via custom error handler, though.
Another feasible option for you is that define user error handler that ignores
this error. Since we are not going to add new serialize handler to released
branch, it would be most feasible option for you. Or write your own module that
monitor assignments and raise error for invalid.
------------------------------------------------------------------------
[2013-08-10 10:53:36] spam2 at rhsoft dot net
yes it is *saved* after script execution
but that is no excuse not store the script path and throw it out in the error message so someone
knows which of the some hundret thousands scripts on the server is triggering the error to debug
whatever application
so again: we do not need a *incompatible* new session handler, we need proper error-reporting and
"in unknown" is always a *major bug* and design flaw
------------------------------------------------------------------------
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=65359
--
Edit this bug report at https://bugs.php.net/bug.php?id=65359&edit=1