Bug #61285 [Com]: SSL connections do not timeout
Edit report at https://bugs.php.net/bug.php?id=61285&edit=1 ID: 61285 Comment by: boen dot robot at gmail dot com Reported by:tony2...@php.net Summary:SSL connections do not timeout Status: Open Type: Bug Package:OpenSSL related PHP Version:5.4SVN-2012-03-05 (SVN) Block user comment: N Private report: N New Comment: At the risk of being annoying, I'd like to repeat what I said in GitHub, in case it was missed... bbroerman's changes have been done already. So, could this be merged now please? (This issue also affects me, obviously...) Previous Comments: [2013-01-23 03:05:04] bbroerman at bbroerman dot net When I get a chance, I'll back out the changes, and re-do them with the same whitespace as the original... May be a couple weeks. [2013-01-23 02:40:49] bbroerman at bbroerman dot net I sent the pull request a couple days ago. [2013-01-21 09:21:45] ras...@php.net Tony, you can just add ?w=1 to the Github URL and it will show you the diff without the whitespace changes. [2013-01-21 09:20:27] paj...@php.net Could you create a pull request as well? Much easier to track and comment :) [2013-01-21 09:16:11] tony2...@php.net Uhm.. for some reason Github shows a lot of whitespace changes there. Could you try to rewrite the patch to avoid them? 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=61285 -- Edit this bug report at https://bugs.php.net/bug.php?id=61285&edit=1
[PHP-BUG] Req #60810 [NEW]: Persistent streams
From: Operating system: Any PHP version: Irrelevant Package: Streams related Bug Type: Feature/Change Request Bug description:Persistent streams Description: It would be really useful (performance wise) for many kinds of streams (particularly php://memory and php://temp streams) to be persistent, or more precisely, to have the option to be persistent. In the case of php://memory and php://temp, I realize there's Wincache and APC for that, but I'm talking about this not requiring an extension, plus, is available for other kinds of streams (http, ftp, etc.) too. To avoid any BC breaks, I suggest a new function, let's say pfopen(), that will be equivalent to fopen(), except that its first argument will be a persistent ID (to allow multiple persistent handles to the same resource/connection), and it will reuse a stream if one is already created within the current PHP process. -- Edit bug report at https://bugs.php.net/bug.php?id=60810&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60810&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60810&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60810&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60810&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60810&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60810&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60810&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60810&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60810&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60810&r=support Expected behavior: https://bugs.php.net/fix.php?id=60810&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60810&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60810&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60810&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60810&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60810&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60810&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60810&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60810&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60810&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60810&r=mysqlcfg
[PHP-BUG] Bug #65137 [NEW]: stream_select misleads when TLS socket is used
From: boen dot robot at gmail dot com
Operating system: Windows Server 2008 R2
PHP version: 5.5.0
Package: Streams related
Bug Type: Bug
Bug description:stream_select misleads when TLS socket is used
Description:
When stream_select() is called on a socket stream created by
stream_socket_client() which uses TLS (with ADH), it seems to report too
early. That is, it would report that that the stream can be read, but then
when you try to read it, it would block, and potentially fail.
The exact same code, if called without encryption, would always work just
fine. Also, if right before receiving, the script is made to sleep for a
while (in my case, about 100 miliseconds did the trick), the script is also
fine.
Sample code is hard to give, as this occurs only when the server sends
large enough data at once over the encrypted connection, and I seem to be
unable to mock a TLS+ADH server with PHP (which is a separate issue that,
at this point, could be just me being stupid).
I *think* the issue might be that stream_select() reports on the underlying
socket (i.e. the data being received before decryption), rather than the
*readable data* from the socket, while fread() blocks until there's at
least 1 byte of readable data to be read. But this shouldn't be so IMHO.
Note that this occurs not just with PHP 5.5.0, but also the latest releases
of 5.4.16 and 5.3.26, and at least as early as 5.3.8.
Test script:
---
NOTE: This script is an "approximation" so to speak, in that it
demonstrates the exact settings for the client where this occurs, but due
to the lack of a mock server, it's not confirmed to always fail.
array('ciphers' => 'ADH'))
)
);
fwrite($socket, chr(6) . '/login' . chr(0));
$r = array($socket);
$w = $e = null;
if (1 === stream_select($r, $w, $e, null)) {
echo fread($socket, 1);
} else {
echo 'stream_select() returned with errors';
}
Expected result:
stream_select() should only report the encrypted socket as readable if
there's at least 1 byte of readable data in the buffer that can be read by
fread().
Actual result:
--
stream_select() reports the encrypted socket as readable, but fread()
blocks, and may even time out.
--
Edit bug report at https://bugs.php.net/bug.php?id=65137&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65137&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65137&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65137&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65137&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65137&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65137&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65137&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65137&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65137&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65137&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65137&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65137&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65137&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65137&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65137&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65137&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65137&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65137&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65137&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65137&r=mysqlcfg
Bug #65137 [Opn]: stream_select misleads when TLS socket is used
Edit report at https://bugs.php.net/bug.php?id=65137&edit=1
ID: 65137
User updated by:boen dot robot at gmail dot com
Reported by:boen dot robot at gmail dot com
Summary:stream_select misleads when TLS socket is used
Status: Open
Type: Bug
Package:Streams related
Operating System: Windows Server 2008 R2
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
On a quick inspection of the relevant source (and I must note I know nothing
about PHP's internals, nor have I compiled PHP, so take this with a grain of
salt), this seems to be the problematic part:
https://github.com/php/php-src/blob/642721b38a9c5ebf336c81027c0dafd6f9246bd6/ext/openssl/xp_ssl.c#L814
For some reason, when doing a cast for stream_select(), the actual socket is
returned directly, as opposed to this happening after an "sslsock->ssl_active"
check, like the other casts, which I'm guessing is causing the gap between what
stream_select() says, and what fread() does. What's the reason for it being
that way anyway?
Previous Comments:
--------
[2013-06-26 19:01:21] boen dot robot at gmail dot com
Description:
When stream_select() is called on a socket stream created by
stream_socket_client() which uses TLS (with ADH), it seems to report too early.
That is, it would report that that the stream can be read, but then when you
try to read it, it would block, and potentially fail.
The exact same code, if called without encryption, would always work just fine.
Also, if right before receiving, the script is made to sleep for a while (in my
case, about 100 miliseconds did the trick), the script is also fine.
Sample code is hard to give, as this occurs only when the server sends large
enough data at once over the encrypted connection, and I seem to be unable to
mock a TLS+ADH server with PHP (which is a separate issue that, at this point,
could be just me being stupid).
I *think* the issue might be that stream_select() reports on the underlying
socket (i.e. the data being received before decryption), rather than the
*readable data* from the socket, while fread() blocks until there's at least 1
byte of readable data to be read. But this shouldn't be so IMHO.
Note that this occurs not just with PHP 5.5.0, but also the latest releases of
5.4.16 and 5.3.26, and at least as early as 5.3.8.
Test script:
---
NOTE: This script is an "approximation" so to speak, in that it demonstrates
the exact settings for the client where this occurs, but due to the lack of a
mock server, it's not confirmed to always fail.
array('ciphers' => 'ADH'))
)
);
fwrite($socket, chr(6) . '/login' . chr(0));
$r = array($socket);
$w = $e = null;
if (1 === stream_select($r, $w, $e, null)) {
echo fread($socket, 1);
} else {
echo 'stream_select() returned with errors';
}
Expected result:
stream_select() should only report the encrypted socket as readable if there's
at least 1 byte of readable data in the buffer that can be read by fread().
Actual result:
--
stream_select() reports the encrypted socket as readable, but fread() blocks,
and may even time out.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65137&edit=1
#48898 [NEW]: readOuterXML() doesn't work on DTDs
From: boen dot robot at gmail dot com
Operating system: Windows Vista Ultimate x64 SP2
PHP version: 5.3.0
PHP Bug Type: XML Reader
Bug description: readOuterXML() doesn't work on DTDs
Description:
When reading an XML document with XMLReader, you can't use readOuterXML()
to read the value of some node types, DTD being the most noticeable and
disturbing one.
While for readInnerXML(), the "inner" part may be hard to define in those
node types, the "outer" is always clearly the whole node, and all of its
descendants.
If the root of the problem is in libxml, may I ask the maintainers of this
extension to forward this to libxml's authors? I'm not a C user of libxml,
so coming in with a runnable test case for libxml's authors would be hard.
PHP runs on Apache 2.2.9 as CGI, and is the VC6 x86 Thread-safe build
(just in case it matters).
Reproduce code:
---
XML('http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
It works...
It works!
');
$reader->read();
echo $reader->readOuterXML();
?>
Expected result:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
Actual result:
--
An empty string.
--
Edit bug report at http://bugs.php.net/?id=48898&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48898&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48898&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48898&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48898&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48898&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48898&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48898&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48898&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48898&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48898&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48898&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48898&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48898&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48898&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48898&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48898&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48898&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48898&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48898&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48898&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48898&r=mysqlcfg
#44269 [NEW]: Inconsistent parameter validation
From: boen dot robot at gmail dot com
Operating system: Windows XP SP2
PHP version: 5.2.5
PHP Bug Type: XSLT related
Bug description: Inconsistent parameter validation
Description:
XSLTProcessor::setParameter() seems to be validating if its arguments are
valid in XSLT context, but not always. What I'm even more curious about is
that these warnings never get into the LibXML's error buffer. That is,
libxml_get_errors() returns an empty array when such warnings are to be
displayed (regardless of the libxml_use_internal_errors() value).
To make description of the bug simpler, I'm only altering the $params
array in the sample code below (which I used to isolate the bug(s?)).
Another (minor) part of this issue is that the namespace is never
validated to be an URI (I can live without that one though), regardless of
whether two or three arguments are used.
Reproduce code:
---
importStylesheet(@DOMDocument::loadXML('
http://www.w3.org/1999/XSL/Transform";>
test1:
test2:
'));
$proc->setParameter(null, $params);
echo $proc->transformToXML(DOMDocument::loadXML(''));
print_r(libxml_get_errors());
?>
Expected result:
$params = array(
'test1'=>'legal value',
'1'=>'invalid parameter name, but a legal value',
'test2'=>'another legal value');
Should create a warning for $params being an invalid parameter array,
ideally pointing explicitly to the "1" parameter, and still apply "test2",
since it's a valid parameter. The warning should be part of the LibXML
error buffer.
$params = array(
'test1'=> new XSLTProcessor,
'test2'=>'legal value');
Should generate a warning in LibXML's error buffer because of the
XSLTProcessor object. This error belongs there, as "normal" arrays can have
objects as their values. The same is applicable for any other object,
though I'm not sure if __toString() has any influence on the outcome with
setParameter(). I believe it should be tried before a warning is reported,
and if it's not available, "test1" should not be populated at all (or
should I say its last successfully applied value should be used during the
transformation).
The same should apply if setParameter() was used with three arguments
instead of two, like
$proc->setParameter(null, 'test1', 'legal value');
$proc->setParameter(null, '1', 'invalid parameter name, but a legal
value');
$proc->setParameter(null, 'test2', 'another legal value');
and
$proc->setParameter(null, 'test1', new XSLTProcessor);
$proc->setParameter(null, 'test2', 'legal value');
respectively.
Actual result:
--
$params = array(
'test1'=>'legal value',
'1'=>'invalid parameter name, but a legal value',
'test2'=>'another legal value');
Shows a warning about $params not being a valid parameter array and
doesn't apply any parameter in the array appearing after the first invalid
parameter (in the case above: "test2"). No entry in LibXML's error buffer
is generated.
$params = array(
'test1'=> new XSLTProcessor,
'test2'=>'legal value');
Throws a catchable fatal error appearing on screen, and executes the
transformation, giving "test1" a value of the string "Object", and giving
"test2" its expected "legal value".
When using three arguments instead of two, no warnings ever occur anywhere
for the first case, and
$proc->setParameter(null, 'test1', new XSLTProcessor);
shows "Wrong parameter count" warning, instead of trying to turn the
object into string, and using
$proc->setParameter(null, 'test1',(string) new XSLTProcessor);
shows the same error as when using an array, only it doesn't populate
"test1" with the value "Object".
(I haven't tried it, but I'm guessing resources may have similar issues)
--
Edit bug report at http://bugs.php.net/?id=44269&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44269&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44269&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44269&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44269&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44269&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44269&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44269&r=needscript
Try newer version:
#44269 [Bgs]: Inconsistent parameter validation
ID: 44269
User updated by: boen dot robot at gmail dot com
Reported By: boen dot robot at gmail dot com
Status: Bogus
Bug Type: XSLT related
Operating System: Windows XP SP2
PHP Version: 5.2.5
Assigned To: rrichards
New Comment:
I think you're misunderstanding where the issue is here.
It's not that the errors are not part of LibXML's buffer... ok, so I
thought they should be, I was wrong. Sorry about that.
The real issue is that those errors don't always appear, and have
different impacts depending on how you set the parameters.
When using an array of name=>value pairs, the results should be the
same as if you used a set of setParameter() calls with a single
name/value pair each.
In particular, parameters with invalid names and/or values should not
be passed along and a warning should appear (or a catchable fatal error,
or an exception...). All valid name/value pairs (whether in an array or
not) should get passed to libxslt where the parameter may be ignored if
it doesn't exist.
What instead happens is that if a valid parameter is part of an array
where a previous parameter is invalid, that parameter doesn't get
passed. In addition, specifying this invalid parameter without an array
(but in a stand alone setParameter() call) doesn't create the warning.
In addition, specifying an invalid stand alone value shows a warning
about wrong parameter count which is completely unrelated. Not to
mention that the fallbacks of invalid values are different depending on
whether the invalid value is in an array or not.
Please review the initial examples again and tell me if this
inconsistent behaviour (hence the name) is really a corrent one.
Previous Comments:
[2008-10-20 13:07:08] [EMAIL PROTECTED]
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
All of the encountered errors are PHP errors as nothing has even been
passed to the libxslt layer, so libxml_errors are never populated.
Objects need to be convertible to strings to be used as parameters.
Not passing convertible data results in exactly what you have seen.
--------
[2008-02-27 17:23:11] boen dot robot at gmail dot com
Description:
XSLTProcessor::setParameter() seems to be validating if its arguments
are valid in XSLT context, but not always. What I'm even more curious
about is that these warnings never get into the LibXML's error buffer.
That is, libxml_get_errors() returns an empty array when such warnings
are to be displayed (regardless of the libxml_use_internal_errors()
value).
To make description of the bug simpler, I'm only altering the $params
array in the sample code below (which I used to isolate the bug(s?)).
Another (minor) part of this issue is that the namespace is never
validated to be an URI (I can live without that one though), regardless
of whether two or three arguments are used.
Reproduce code:
---
importStylesheet(@DOMDocument::loadXML('
http://www.w3.org/1999/XSL/Transform";>
test1:
test2:
'));
$proc->setParameter(null, $params);
echo $proc->transformToXML(DOMDocument::loadXML(''));
print_r(libxml_get_errors());
?>
Expected result:
$params = array(
'test1'=>'legal value',
'1'=>'invalid parameter name, but a legal value',
'test2'=>'another legal value');
Should create a warning for $params being an invalid parameter array,
ideally pointing explicitly to the "1" parameter, and still apply
"test2", since it's a valid parameter. The warning should be part of the
LibXML error buffer.
$params = array(
'test1'=> new XSLTProcessor,
'test2'=>'legal value');
Should generate a warning in LibXML's error buffer because of the
XSLTProcessor object. This error belongs there, as "normal" arrays can
have objects as their values. The same is applicable for any other
object, though I'm not sure if __toString() has any influence on the
outcome with setParameter(). I believe it should be tried before a
warning is reported, and if it's not available, "test1" should not be
populated at all (or should I say its last successfully applied value
should be used during the transformation).
The same should apply if setParameter() was used with three arguments
instead of two, like
$proc->setParameter(null, 'test1', 'legal value');
$proc->setParameter(null, '1', 'invali
#47140 [NEW]: Add UTF-8 to convert_cyr_string()
From: boen dot robot at gmail dot com Operating system: Windows Vista Ultimate x64 PHP version: 5.2.8 PHP Bug Type: Feature/Change Request Bug description: Add UTF-8 to convert_cyr_string() Description: Many comments in the convert_cyr_string() function provide some ways of converting cyrilic charsets to UTF-8. It would be great to have those compiled in, and ideally, also have the other convertion - from UTF-8 into the cyrillic charsets. With the iconv library and those comments in place, how difficult would it be to do that? (BTW, when I've used iconv to do UTF-8 to Windows-1251 , I sometimes get an unsupported character error and I'm not sure why even though the text never had any exotic characters... but that's another thing that may be my fault, so I don't consider it a bug just yet) -- Edit bug report at http://bugs.php.net/?id=47140&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47140&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47140&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47140&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47140&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47140&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47140&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47140&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47140&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47140&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47140&r=support Expected behavior: http://bugs.php.net/fix.php?id=47140&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47140&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47140&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47140&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47140&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47140&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47140&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47140&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47140&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47140&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47140&r=mysqlcfg
#41224 [NEW]: Quotes don't work on a program's path.
From: boen dot robot at gmail dot com Operating system: Windows XP Professional SP2 PHP version: 5CVS-2007-04-29 (snap) PHP Bug Type: Program Execution Bug description: Quotes don't work on a program's path. Description: When executing a command with system(), exec(), passthru() or shell_exec(), quotes in the program's path are not accepted and nothing is returned (except error code 1). The same command with quotes around the path works from the command line. Without quotes, the program only works if there are no spaces in the paths, which is where the real problem lies. Reproduce code: --- Returns 1 (because of the "print $status" - otherwise it's an empty default HTML). Returns the output of the program, and 0 after it. This particular case works, but if the path had spaces, there would be no way to execute the program... not withing PHP anyway (a bat file could be a solution, but still...). Expected result: The program should run even if the path to it has quotes and it's output should be then printed. Actual result: -- The first code, when executed results in an error, which wouldn't be raised with the same command executed directly from the command line. -- Edit bug report at http://bugs.php.net/?id=41224&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41224&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41224&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41224&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41224&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41224&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41224&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41224&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41224&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41224&r=support Expected behavior:http://bugs.php.net/fix.php?id=41224&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41224&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41224&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41224&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41224&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41224&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41224&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41224&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41224&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41224&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41224&r=mysqlcfg
#41224 [Bgs]: Quotes don't work on a program's path.
ID: 41224 User updated by: boen dot robot at gmail dot com Reported By: boen dot robot at gmail dot com Status: Bogus Bug Type: Program Execution Operating System: Windows XP Professional SP2 PHP Version: 5CVS-2007-04-29 (snap) New Comment: Sorry. I searched the bug database, but couldn't find one. Only one about quotes on arguments, but none for program's paths. Can I have a link to this issue please? I would like to see the resolution (especially if by that you mean "workaround"). Previous Comments: [2007-04-29 15:04:43] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. [2007-04-29 13:13:04] boen dot robot at gmail dot com Description: When executing a command with system(), exec(), passthru() or shell_exec(), quotes in the program's path are not accepted and nothing is returned (except error code 1). The same command with quotes around the path works from the command line. Without quotes, the program only works if there are no spaces in the paths, which is where the real problem lies. Reproduce code: --- Returns 1 (because of the "print $status" - otherwise it's an empty default HTML). Returns the output of the program, and 0 after it. This particular case works, but if the path had spaces, there would be no way to execute the program... not withing PHP anyway (a bat file could be a solution, but still...). Expected result: The program should run even if the path to it has quotes and it's output should be then printed. Actual result: -- The first code, when executed results in an error, which wouldn't be raised with the same command executed directly from the command line. -- Edit this bug report at http://bugs.php.net/?id=41224&edit=1
#41577 [NEW]: DOTNET is successful once per server run
From: boen dot robot at gmail dot com Operating system: Windows XP Professional SP2 PHP version: 5CVS-2007-06-03 (snap) PHP Bug Type: COM related Bug description: DOTNET is successful once per server run Description: When I run any PHP file using the DOTNET class, The class is first run as it should (the sample from the documentation does ineed produce "Hello .Net"), but after a page refresh, or if a navigate away from the page and go back, the server crashes. I have PHP installed locally as an Apache 2.2.4 module. I tryed turning off my antivirus (NOD32 in case it's relevant), but that didn't helped either. I have all .NET 1.1, .NET 2.0 and .NET 3.0 with all updates from Microsoft Update. Reproduce code: --- Expected result: The file should output "created" every time it's executed, unless perhaps I had an error in the constructor, in which case it should output "not created". Actual result: -- "created" is only outputted the first time. After that... A server crash with this in the error details: szAppName : httpd.exe szAppVer : 2.2.4.0 szModName : php5ts.dll szModVer : 5.2.4.4 offset : 000e622d -- Edit bug report at http://bugs.php.net/?id=41577&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41577&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41577&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41577&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41577&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41577&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41577&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41577&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41577&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41577&r=support Expected behavior:http://bugs.php.net/fix.php?id=41577&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41577&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41577&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41577&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41577&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41577&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41577&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41577&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41577&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41577&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41577&r=mysqlcfg
Bug #54563 [Com]: invalid crt parameters on stream_select
Edit report at https://bugs.php.net/bug.php?id=54563&edit=1
ID: 54563
Comment by: boen dot robot at gmail dot com
Reported by:alex at phpguide dot co dot il
Summary:invalid crt parameters on stream_select
Status: Open
Type: Bug
Package:Streams related
Operating System: windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I have the same issue with Windows Server 2008 R2, PHP 5.3.8.
Previous Comments:
[2011-06-06 14:41:55] jinmoku at hotmail dot com
I'have the same issue with this simple code :
$sock = fsockopen('127.0.0.1',80);
$e = array($sock);
$w = $r = null;
while(stream_select($r, $w, $e, 0));
[2011-04-18 21:03:21] alex at phpguide dot co dot il
Description:
Apparently there are some errors selecting streams on windows platforms
when calling some native win functions.
linux wouldnt reproduce
5.3.6 vc9
Test script:
---
https://bugs.php.net/bug.php?id=54563&edit=1
