Bug #17250: Extend detection capabilities of getimagesize
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: Extend detection capabilities of getimagesize It would be nice if getimagesize() could be extended to recognize more image file types, as the corresponding command in ImageMagick does. I'm using PHP as a shell script and it would be useful not to have to do exec calls to ImageMagick, and also simplify the Image_Transform libray i'm writing for PEAR. Formats detected by ImageMagick: http://imagemagick.org/www/formats.html Even if the list isn't as extensive, it would be really useful! -- Edit bug report at http://bugs.php.net/?id=17250&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17250&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17250&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17250&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17250&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17250&r=support Expected behavior: http://bugs.php.net/fix.php?id=17250&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17250&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17250&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17250&r=globals
Bug #17272 Updated: Failure to read Flash MX file size
ID: 17272 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: SWF related Operating System: N/A PHP Version: 4.1.2 New Comment: The problem is with the getimagesize() function and its detection routines which don't detect Flash 6/MX content. Previous Comments: [2002-05-16 12:00:44] [EMAIL PROTECTED] Flash file size detection seems to not work for Flash files published in the new Flash "MX" (version 6). When published to version 5 or lower, it works. -- Edit this bug report at http://bugs.php.net/?id=17272&edit=1
Bug #16305: curl post doesn't behave as per the manual
From: [EMAIL PROTECTED]
Operating system: Any
PHP version: 4.1.2
PHP Bug Type: cURL related
Bug description: curl post doesn't behave as per the manual
The curl extension is not behaving as described in the manual.
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead of
application/x-www-form-urlencoded. This is wrong: the multipart header
should only be used when CURLOPT_PUT is set. To quote the PHP manual:
{{{CURLOPT_POST: Set this option to a non-zero value if you want PHP to do
a regular HTTP POST. This POST is a normal
application/x-www-form-urlencoded kind, most commonly used by HTML
forms.}}}
Here is what the author of curl (Daniel Stenberg) says - full message at
:
{{{I took a tour into the inner workings of the php curl wrapper code and
I've now returned to tell about my findings! ;-)
When you pass an array to CURLOPT_POSTFIELDS, it is passed as a
multipart/form-data post exactly as you describe. The problem with this is
that it uses the libcurl function curl_formparse() to accomplish this, and
that is a lame function(*).
It does not support newlines in the contents like you tried here.
The wrapper should instead use the new (and much better) curl_formadd()
function for this purpose. It does not have this newline problem.
(*) = yet it was the only available one for a very long time.}}}
I think there is enough evidence here to change the behaviour of the
extension - I think it can be done without breaking backwards
compatibility. The extension was never meant to behave like this, as the
manual testifies.
Regards,
Peter Bowyer.
--
Edit bug report at http://bugs.php.net/?id=16305&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16305&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16305&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16305&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16305&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16305&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16305&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16305&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16305&r=submittedtwice
Bug #16305 Updated: curl post doesn't behave as per the manual
ID: 16305
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: cURL related
Operating System: Any
PHP Version: 4.1.2
New Comment:
Unfortunately, like 90% of people using PHP I am reliant on my host for
compiling and installing PHP, so I can't test it :-(
Previous Comments:
[2002-04-04 07:34:52] [EMAIL PROTECTED]
PHP 4.2.0-dev does not use curl_formparse..please try
the RC2 from http://www.php.net/~derick/
[2002-03-27 03:49:03] [EMAIL PROTECTED]
The curl extension is not behaving as described in the manual.
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead
of application/x-www-form-urlencoded. This is wrong: the multipart
header should only be used when CURLOPT_PUT is set. To quote the PHP
manual:
{{{CURLOPT_POST: Set this option to a non-zero value if you want PHP to
do a regular HTTP POST. This POST is a normal
application/x-www-form-urlencoded kind, most commonly used by HTML
forms.}}}
Here is what the author of curl (Daniel Stenberg) says - full message
at :
{{{I took a tour into the inner workings of the php curl wrapper code
and I've now returned to tell about my findings! ;-)
When you pass an array to CURLOPT_POSTFIELDS, it is passed as a
multipart/form-data post exactly as you describe. The problem with this
is that it uses the libcurl function curl_formparse() to accomplish
this, and that is a lame function(*).
It does not support newlines in the contents like you tried here.
The wrapper should instead use the new (and much better) curl_formadd()
function for this purpose. It does not have this newline problem.
(*) = yet it was the only available one for a very long time.}}}
I think there is enough evidence here to change the behaviour of the
extension - I think it can be done without breaking backwards
compatibility. The extension was never meant to behave like this, as
the manual testifies.
Regards,
Peter Bowyer.
--
Edit this bug report at http://bugs.php.net/?id=16305&edit=1
