Req #48674 [Com]: fopen() ftp wrapper and SIZE command
Edit report at https://bugs.php.net/bug.php?id=48674&edit=1
ID: 48674
Comment by: jesse at reltru dot com
Reported by: bmorel at ssi dot fr
Summary: fopen() ftp wrapper and SIZE command
Status: Open
Type: Feature/Change Request
Package: Streams related
Operating System: CentOS 5
PHP Version: 5.2.10
Block user comment: N
Private report: N
New Comment:
Running into the same issue and would like to provide additional information
Ubuntu 10.04.3 LTS
PHP Version => 5.3.2-1ubuntu4.9
When using file_get_contents or fopen to connect to an FTP server that does not support the SIZE
command the process will exit early
wget works correctly
tcpdump -vvvnA shows the following for file_get_contents
220 FTP
USER *****
331 Password required
PASS *****
230 User logged in
TYPE I
200 Type set to I, binar
SIZE /*****.***
500 Command not recogniz
221 You could at least s
Replaced username, pass and file with *'s but they are correct in the capture, after the 221
the process ends and throws an exception.
Capturing a wget shows the following:
220 FTP
USER *****
331 Password required
PASS *****
230 User logged in
SYST
500 Command not recogniz
PWD
257 Current directory is
TYPE I
200 Type set to I, binar
CWD /*****
250 Changed directory to
SIZE *****.***
500 Command not recogniz
PASV
227 Entering Passive Mod
RETR *****.***
150 Opening BINARY mode
Data is sent between FTP server and client successfully
Even though the attempt from wget to identify the file failed, it still attempts to download the
file and works successfully
Previous Comments:
------------------------------------------------------------------------
[2009-06-24 11:15:50] bmorel at ssi dot fr
Description:
------------
(Request for reopening bug #35765)
Sorry to restart this thread more than 3 years later, but I'm facing the very same problem and
cannot add a comment on a "won't fix" bug.
The problem concerns the fopen()'s ftp wrapper incorrectly relying on the ftp SIZE command to
check whether a file is downloadable.
I do think that's not a correct behaviour.
For example I'm using a ftp server from a well-known affiliate marketing company, that's
serving "virtual" files, that are not displayed in the ftp server as such, but
downloadable by any ftp client I could try... except php's fopen wrapper.
The problem is that this server returns a "550 Not a plain file" error for a SIZE request.
This is not a plain file, but it is perfectly downloadable.
The SIZE command is *not* standardized in RFC 959. It may be used by ftp clients, but only to try to
get some information about the file.
Refusing to download a file due to a SIZE command failing is not RFC compliant, while the servers
the previous bug reporter and I are using, are.
Reproduce code:
---------------
$fp = fopen("ftp://example.com/test.xml.gz",
"rb");
var_dump($fp);
Expected result:
----------------
bool(true)
Actual result:
--------------
Warning: fopen(ftp://example.com/test.xml.gz) [function.fopen]: failed to open stream: FTP server
reports 550 /test.xml.gz: not a plain file.
bool(false)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=48674&edit=1
Thread (2 messages)