Bug #47202 [Wfx->ReO]: FTP fopen wrapper and # in file names

2012-06-16 Thread langemeijer
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

2012-06-18 Thread langemeijer
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

2012-06-08 Thread casper at langemeijer dot eu
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