Bug #47202 [Wfx->ReO]: FTP fopen wrapper and # in file names
Edit report at https://bugs.php.net/bug.php?id=47202&edit=1
ID: 47202
Updated by: langemei...@php.net
Reported by:smlerman at gmail dot com
Summary:FTP fopen wrapper and # in file names
-Status: Wont fix
+Status: Re-Opened
Type: Bug
Package:Streams related
Operating System: *
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
I was able to fix the problem for the ssh2 wrapper. I assume it can be fixed
for
ftp too. See bug #59794
Previous Comments:
[2009-03-03 07:05:27] hrad...@php.net
The php_url_parse_ex function intentionally strips the # character from the
filename. I did some research and see that this was done to fix Bug #31705
(http://bugs.php.net/bug.php?id=31705).
>From http://www.w3.org/Addressing/URL/4_URI_Recommentations.html :
The hash ("#", ASCII 23 hex) character is reserved as a delimiter to separate
the URI of an object from a fragment identifier.
This behavior is intentional.
[2009-01-23 15:22:38] smlerman at gmail dot com
Description:
It seems that the FTP fopen wrapper truncates file names when it encounters a
pound sign (#). The FTP server's log shows a request for "file".
I have tried replacing the # with %23 (the result of urlencode), but the server
sees that as a request for "file%231.txt".
Reproduce code:
---
// Use fopen wrapper
$data = file_get_contents("ftp://username:passw...@ftp.example.com/file
#1.txt");
var_dump(strlen($data));
// Use ftp_* functions
$conn = ftp_connect('ftp.example.com');
ftp_login($conn, 'username', 'password');
ftp_get($conn, 'C:\\test.txt', 'file#1.txt', FTP_BINARY);
var_dump(filesize('C:\\test.txt'));
Expected result:
int(7)
int(7)
Actual result:
--
Warning: file_get_contents(ftp://...@ftp.example.com/file#1.txt) [function.file-get-contents]: failed to
open stream: FTP server reports 550 /file : The system cannot find the path
specified. in...
int(0)
int(7)
--
Edit this bug report at https://bugs.php.net/bug.php?id=47202&edit=1
Bug #61272 [Nab->ReO]: ob_start callback get passed empty string
Edit report at https://bugs.php.net/bug.php?id=61272&edit=1
ID: 61272
Updated by: langemei...@php.net
Reported by:peacech at gmail dot com
Summary:ob_start callback get passed empty string
-Status: Not a bug
+Status: Re-Opened
Type: Bug
Package:Output Control
Operating System: Arch 32 bit
PHP Version:5.4.0
Block user comment: N
Private report: N
Previous Comments:
[2012-06-08 08:03:50] casper at langemeijer dot eu
Mike, I've dug a bit deeper into this problem, and must conclude that this
really is a bug, or at least a change of behaviour.
I think test tests/output/ob_017.phpt is faulty too. I corrected bot output.c
and the test in the patch I supplied.
In PHP 5.3 the callback function is called with the contents of the output
buffer when ob_clean or ob_end_clean is called. The output will be fed to the
callback function, but is erased right after that call.
After your output buffering rewrite the output buffer is cleaned before the
callback is called.
I see no valid reason for a functional change. You're supplying the callback
with a flag so that if needed the callback function could do this itself if
needed.
[2012-05-18 10:04:18] patrick at procurios dot nl
We are having the same problem and it keeps us from migrating to 5.4. Could you
please fix it?
[2012-03-05 14:43:25] peacech at gmail dot com
Unless ob_start callback specification has changed that for
ob_clean/ob_end_clean, the output is discarded before calling the callback,
then this is a bug. And I have scan the PHP 5.4 changelog and couldn't find
anything mentioning this change.
So let me help by showing where the problem is
In line 1226 of output.c in the distributed PHP 5.4.0 source,
if (flags & PHP_OUTPUT_POP_DISCARD) {
context.op |= PHP_OUTPUT_HANDLER_CLEAN;
orphan->buffer.used = 0;
}
php_output_handler_op(orphan, &context);
orphan->buffer.used should not be set to 0 before calling the callback,
otherwise the callback will be called with empty buffer.
And likewise in line 300 in php_output_clean
So, no, it isn't about appending $output to $buffer.
[2012-03-05 11:23:43] m...@php.net
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.
You should append $output to $buffer.
[2012-03-04 10:53:53] peacech at gmail dot com
Description:
Running test script below with PHP 5.4 outputs
""
Running test script below with PHP 5.3 outputs
"hello"
Test script:
---
https://bugs.php.net/bug.php?id=61272&edit=1
Bug #61272 [Com]: ob_start callback get passed empty string
Edit report at https://bugs.php.net/bug.php?id=61272&edit=1
ID: 61272
Comment by: casper at langemeijer dot eu
Reported by:peacech at gmail dot com
Summary:ob_start callback get passed empty string
Status: Not a bug
Type: Bug
Package:Output Control
Operating System: Arch 32 bit
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Mike, I've dug a bit deeper into this problem, and must conclude that this
really is a bug, or at least a change of behaviour.
I think test tests/output/ob_017.phpt is faulty too. I corrected bot output.c
and the test in the patch I supplied.
In PHP 5.3 the callback function is called with the contents of the output
buffer when ob_clean or ob_end_clean is called. The output will be fed to the
callback function, but is erased right after that call.
After your output buffering rewrite the output buffer is cleaned before the
callback is called.
I see no valid reason for a functional change. You're supplying the callback
with a flag so that if needed the callback function could do this itself if
needed.
Previous Comments:
[2012-05-18 10:04:18] patrick at procurios dot nl
We are having the same problem and it keeps us from migrating to 5.4. Could you
please fix it?
[2012-03-05 14:43:25] peacech at gmail dot com
Unless ob_start callback specification has changed that for
ob_clean/ob_end_clean, the output is discarded before calling the callback,
then this is a bug. And I have scan the PHP 5.4 changelog and couldn't find
anything mentioning this change.
So let me help by showing where the problem is
In line 1226 of output.c in the distributed PHP 5.4.0 source,
if (flags & PHP_OUTPUT_POP_DISCARD) {
context.op |= PHP_OUTPUT_HANDLER_CLEAN;
orphan->buffer.used = 0;
}
php_output_handler_op(orphan, &context);
orphan->buffer.used should not be set to 0 before calling the callback,
otherwise the callback will be called with empty buffer.
And likewise in line 300 in php_output_clean
So, no, it isn't about appending $output to $buffer.
[2012-03-05 11:23:43] m...@php.net
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.
You should append $output to $buffer.
[2012-03-04 10:53:53] peacech at gmail dot com
Description:
Running test script below with PHP 5.4 outputs
""
Running test script below with PHP 5.3 outputs
"hello"
Test script:
---
https://bugs.php.net/bug.php?id=61272&edit=1
