[PHP-BUG] Req #51507 [NEW]: Setting filename for @... multipart uploads
From:
Operating system: n/a
PHP version: 5.2.13
Package: cURL related
Bug Type: Feature/Change Request
Bug description:Setting filename for @... multipart uploads
Description:
Using curl_setopt, you can make a multipart POST by passing an array of
parameters, and if preceded by an @, a file upload is created from the path
following the @.
curl_setopt(CURLOPT_POSTFIELDS, array('myfile'=>"@{$pathname}"));
However, I haven't been able to find a way to set the filename part of the
multipart description, so that it generates e.g.
Content-disposition: form-data; name="myfile";
filename="desiredfilename"
Content-Type: text/plain
That is, there isn't a way to get "desiredfilename" in there. The only
option seems to be for the filename part appears to come from the name of
the file within the path. The cURL command line interface seems to support
explicitly setting the filename different from the name of the source file
with
'-F "@path ; filename=whatever'
so presumably it is possible in the library, but not exposed through the
PHP binding.
In case it was merely passing on the string to the cURL library verbatim, I
tried:
curl_setopt(CURLOPT_POSTFIELDS, array('myfile'=>"@{$pathname};
filename=\"desiredfilename\""));
but that gives an error.
The problem is that the files I have are stored with simple numeric names
and the file names which an external user would know them by are in the
database that indexes the disk files. I have a workround which is to make a
temporary hard link to the file by its user name and give that to cURL, but
I don't think I should really need to do that.
Test script:
---
$now = time(); $tmpdirpath = "/tmp/enspub-{$now}-{$version->id}";
mkdir($tmpdirpath);
$tmpfilepath = "{$tmpdirpath}/" .
mb_ereg_replace('[/?%*:|"<>@~=+]', '_', $version->name); // replace
disallowed characters
link($version->pathname(), $tmpfilepath);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); /* tell me, not echo
*/
curl_setopt($ch, CURLOPT_POST, TRUE);
$post['file'] = "@{$tmpfilepath}";
/* ... and other $post settings ... */
curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
$data = curl_exec($ch);
/* ... error checking ... */
curl_close($ch);
@unlink($tmpfilepath);
@rmdir($tmpdirpath);
Expected result:
It works, but I'd like to be able to set the filename explicitly without
copying the file.
Actual result:
--
n/a
--
Edit bug report at http://bugs.php.net/bug.php?id=51507&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51507&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51507&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51507&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51507&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51507&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51507&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51507&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51507&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51507&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51507&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51507&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51507&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51507&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51507&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51507&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51507&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51507&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51507&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51507&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51507&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51507&r=mysqlcfg
[PHP-BUG] Bug #53971 [NEW]: isset() and empty() produce apparently spurious runtime error
From:
Operating system: Linux, Redhat Enterprise
PHP version: 5.3.5
Package: Arrays related
Bug Type: Bug
Bug description:isset() and empty() produce apparently spurious runtime error
Description:
First, apologies, this is 5.3.3. I have no means of upgrading to check
whether
this is a fixed issue. I can't see anything similar in the bug database.
An expression of the form
isset($obj->m['a']['b'])
produces a runtime error when m is not actually an array but a zero length
string:
Uninitialized string offset: 0
The same is the case if I use empty instead of isset.
The same code worked in 5.2. Changing it to
isset($obj->m['a']) && isset($obj->m['a']['b'])
works.
isset is not supposed to produce any runtime error, surely, in this kind of
use.
The object member values arise from a database lookup, and normally the
field (m
above) will be a serialized array in the database, but the first time the
database column will be empty, leading to an empty string assignment to m.
In
addition once populated the object is stored in $_SESSION (actually in
$_SESSION['p']['q']) and then $obj is obtained by assignment from the
session,
like this
$session =& $_SESSION['p']; // where $_SESSION['p'] is set in a previous
page
// populate new $obj1 from database
$session['q'] = $obj1;
...
$obj =& $session['q'];
and the offending code is then executed elsewhere some time later.
However, abstracting the code from this much bigger program does not
demonstrate
the problem, which suggests to me something is corrupted somewhere. This is
what
I tried on its own, which is as close as I can reasonably get to the
situation
here, but it works. (The =& are leftovers from what was originally a PHP4
app; I
know all objects are assigned by reference in PHP5).
class c { var $m; }
session_start();
if (! isset($_SESSION['p'])) {
$_SESSION['p'] = array();
echo "set session array";
exit;
}
$session =& $_SESSION['p'];
$obj1 = new c();
$obj1->m = '';
$session['q'] = $obj1;
$obj =& $session['q'];
function check() {
global $obj;
echo (isset($obj->m['a']['b']) ? 'Yes' : 'No');
}
check();
Expected result:
isset to return FALSE
Actual result:
--
runtime error
Uninitialized string offset: 0
--
Edit bug report at http://bugs.php.net/bug.php?id=53971&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53971&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53971&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53971&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53971&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53971&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53971&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53971&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53971&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53971&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53971&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53971&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53971&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53971&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53971&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53971&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53971&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53971&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53971&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53971&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53971&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53971&r=mysqlcfg
Bug #53971 [Bgs]: isset() and empty() produce apparently spurious runtime error
Edit report at http://bugs.php.net/bug.php?id=53971&edit=1
ID: 53971
User updated by:david at frankieandshadow dot com
Reported by:david at frankieandshadow dot com
Summary:isset() and empty() produce apparently spurious
runtime error
Status: Bogus
Type: Bug
Package:Arrays related
Operating System: Linux, Redhat Enterprise
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I appreciate that this is the case. When you say "$obj->m[0] doesn't
exist", yes
I agree, BUT that is what the isset is testing for.
If it SHOULD produce a runtime error, then (a) this is a very subtle
non-upwards
compatible change from 5.2, and (b) the example I quoted does NOT
produce a
runtime error so is a bug.
(And producing a runtime error in these circumstances is terribly
inconvenient,
it means you can't test existence in one go but have to try each element
individually).
If it SHOULD NOT produce a runtime error then there is a problem with
the larger
code I have which follows this pattern and is doing so.
There is a bug here one way or the other: either my larger program is
wrong (but
has worked for years with this code in it) or the example I put in the
bug
report is wrong in that it does not produce an error and never has. At
present
the behaviour is inconsistent.
Previous Comments:
[2011-02-09 17:50:29] dtajchre...@php.net
$obj->m is an empty string. You try to access a non-integer offset.
Non-integer
offsets are converted to
integers. So in other words:
$obj->m['a'] becomes $obj->m[0]
$obj->m is an empty string and $obj->m[0] doesn't exist
This behavior is documented here:
http://us.php.net/manual/en/language.types.string.php
"Warning
Writing to an out of range offset pads the string with spaces.
Non-integer types
are converted to integer.
Illegal offset type emits E_NOTICE. Negative offset emits E_NOTICE in
write but
reads empty string. Only the
first character of an assigned string is used. Assigning empty string
assigns
NUL byte."
Simplifying the problem: http://codepad.org/G31wr4oJ
----------------
[2011-02-09 13:12:44] david at frankieandshadow dot com
Description:
First, apologies, this is 5.3.3. I have no means of upgrading to check
whether
this is a fixed issue. I can't see anything similar in the bug
database.
An expression of the form
isset($obj->m['a']['b'])
produces a runtime error when m is not actually an array but a zero
length
string:
Uninitialized string offset: 0
The same is the case if I use empty instead of isset.
The same code worked in 5.2. Changing it to
isset($obj->m['a']) && isset($obj->m['a']['b'])
works.
isset is not supposed to produce any runtime error, surely, in this kind
of use.
The object member values arise from a database lookup, and normally the
field (m
above) will be a serialized array in the database, but the first time
the
database column will be empty, leading to an empty string assignment to
m. In
addition once populated the object is stored in $_SESSION (actually in
$_SESSION['p']['q']) and then $obj is obtained by assignment from the
session,
like this
$session =& $_SESSION['p']; // where $_SESSION['p'] is set in a
previous page
// populate new $obj1 from database
$session['q'] = $obj1;
...
$obj =& $session['q'];
and the offending code is then executed elsewhere some time later.
However, abstracting the code from this much bigger program does not
demonstrate
the problem, which suggests to me something is corrupted somewhere. This
is what
I tried on its own, which is as close as I can reasonably get to the
situation
here, but it works. (The =& are leftovers from what was originally a
PHP4 app; I
know all objects are assigned by reference in PHP5).
class c { var $m; }
session_start();
if (! isset($_SESSION['p'])) {
$_SESSION['p'] = array();
echo "set session array";
exit;
}
$session =& $_SESSION['p'];
$obj1 = new c();
$obj1->m = '';
$session['q'] = $obj1;
$obj =& $session['q'];
function check() {
global $obj;
echo (isset($obj->m['a']['b']) ? 'Yes' : 'No');
}
check();
Expected result:
isset to return FALSE
Actual result:
--
runtime error
Uninitialized string offset: 0
--
Edit this bug report at http://bugs.php.net/bug.php?id=53971&edit=1
