Hi all,
As you may know, the cURL PHP extension is currently not in sync
(featurewise) with the original libcurl. I started to work on it to
make it as close as possible from the original libcurl. I also did
some cleaning to make it easier to maintain (ordered all the
constants/features by their libcurl version). All those changes were
made on the trunk branch only.
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.
So please, test the new version of the curl extension, review the
code, and give your input on either or not those changes should be
merge on 5.4.1
Thanks
Pierrick
hi Pierrick,
I would rather go with php-next. The amount of changes are not safe
for a now very stable version in 5.3 and 5.4 (same code base), while
the code could be nicer as you did it in trunk.
Cheers,
Hi all,
As you may know, the cURL PHP extension is currently not in sync
(featurewise) with the original libcurl. I started to work on it to
make it as close as possible from the original libcurl. I also did
some cleaning to make it easier to maintain (ordered all the
constants/features by their libcurl version). All those changes were
made on the trunk branch only.I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.So please, test the new version of the curl extension, review the
code, and give your input on either or not those changes should be
merge on 5.4.1Thanks
Pierrick--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2012/3/10 Pierre Joye pierre.php@gmail.com
hi Pierrick,
I would rather go with php-next. The amount of changes are not safe
for a now very stable version in 5.3 and 5.4 (same code base), while
the code could be nicer as you did it in trunk.Cheers,
Hi all,
As you may know, the cURL PHP extension is currently not in sync
(featurewise) with the original libcurl. I started to work on it to
make it as close as possible from the original libcurl. I also did
some cleaning to make it easier to maintain (ordered all the
constants/features by their libcurl version). All those changes were
made on the trunk branch only.I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.So please, test the new version of the curl extension, review the
code, and give your input on either or not those changes should be
merge on 5.4.1Thanks
Pierrick--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Hi, all
I'd like to see a new interface for curl in php ... I have no special
idea how, but I heard from several people that they pretty much don't
like the way curl is implemented in php.
May we have a little brainstorming around that .. may some other
language has some good implementation ...
When I see the list of constants, I feel like that is way to much ...
this could be grouped somehow ...
Bye
Simon
Am 10.03.2012 18:28, schrieb Simon Schick:
I'd like to see a new interface for curl in php ... I have no special
idea how, but I heard from several people that they pretty much don't
like the way curl is implemented in php.
many other people would not like to break their
perfect working code!
2012/3/10 Reindl Harald h.reindl@thelounge.net:
Am 10.03.2012 18:28, schrieb Simon Schick:
I'd like to see a new interface for curl in php ... I have no special
idea how, but I heard from several people that they pretty much don't
like the way curl is implemented in php.many other people would not like to break their
perfect working code!
Hi, Reindl
I do not mean to drop the implementation as it is right now - but
think of something different for the future.
If there would be an additional implementation it would probably be
like mysqli, where you have an oop-implmentation and a non-oop.
Bye
Simon
The oop interface to cURl is already available, take a look at
http://pecl.php.net/package/pecl_http extension. It provides OOP
interface and takes care of many of the input preparation or output
parsing tasks normally you need to do in PHP when working with cURL.
On Sat, Mar 10, 2012 at 12:49 PM, Simon Schick
simonsimcity@googlemail.com wrote:
2012/3/10 Reindl Harald h.reindl@thelounge.net:
Am 10.03.2012 18:28, schrieb Simon Schick:
I'd like to see a new interface for curl in php ... I have no special
idea how, but I heard from several people that they pretty much don't
like the way curl is implemented in php.many other people would not like to break their
perfect working code!Hi, Reindl
I do not mean to drop the implementation as it is right now - but
think of something different for the future.
If there would be an additional implementation it would probably be
like mysqli, where you have an oop-implmentation and a non-oop.Bye
Simon
I think all the php curl bindings should do is expose the power of curl in php with an interface similar to the c interface. I think it's up to third party libraries to put an easier to use interface on top of the curl bindings.
Thanks,
Michael
Am 10.03.2012 18:28, schrieb Simon Schick:
I'd like to see a new interface for curl in php ... I have no special
idea how, but I heard from several people that they pretty much don't
like the way curl is implemented in php.many other people would not like to break their
perfect working code!
--047d7b2ee19338d79004bae668f3
Content-Type: text/plain; charset=ISO-8859-1Hi all,
As you may know, the cURL PHP extension is currently not in sync
(featurewise) with the original libcurl. I started to work on it to
make it as close as possible from the original libcurl. I also did
some cleaning to make it easier to maintain (ordered all the
constants/features by their libcurl version). All those changes were
made on the trunk branch only.I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.
Hi Pierrick,
as long as your implementation does not contain crucial security fixes,
I prefer not having it in 5.4 Let's try to keep 5.4 as stable as possible
and minimize the amount of new code.
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.
Can't you make it also available as pecl extension, which could be built
on 5.4? This way people could enjoy the benefits of your work without
stable branch being disrupted and BC problems raised.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I'd sure like a PHP extension that didn't have this obvious and nasty bug:
https://bugs.php.net/bug.php?id=46439
On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.Can't you make it also available as pecl extension, which could be built
on 5.4? This way people could enjoy the benefits of your work without
stable branch being disrupted and BC problems raised.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
hi Tom,
For one, it is mapped to the libcurl constants and behavior.
Also this but report contains clear comment about this issue being a
documentation problem, contribution welcome :)
If you consider it as something that should be changed, then please
feel free to add a comment there as well, or a patch :)
But that's not really what we discuss here but the new code proposed
by Pierrick.
Cheers,
I'd sure like a PHP extension that didn't have this obvious and nasty bug:
https://bugs.php.net/bug.php?id=46439
On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.Can't you make it also available as pecl extension, which could be built
on 5.4? This way people could enjoy the benefits of your work without
stable branch being disrupted and BC problems raised.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I do see now that at curl did introduce the @ craziness. So it is unfair of
me to single out PHP for introducing it. I'm not sure if the @ syntax is a
sneaky feature of the standard C API, but it's definitely a sneaky feature
of the command line utility.
I did include a comment there when I first opened that bug report,
proposing a more appropriate and sustainable interface. Documentation
changes would make it possible to avoid the problem by looking carefully
for strange "gotchas" in the fine print - but not to actually submit a
value starting with a @, if, y'know, I wanted to do something crazy-nutty
like send arbitrary data legal in any other form submission (:
Apologies for hijacking the discussion.
The '@' business does not come from libcurl. Native C libcurl
hi Tom,
For one, it is mapped to the libcurl constants and behavior.
Also this but report contains clear comment about this issue being a
documentation problem, contribution welcome :)If you consider it as something that should be changed, then please
feel free to add a comment there as well, or a patch :)But that's not really what we discuss here but the new code proposed
by Pierrick.Cheers,
I'd sure like a PHP extension that didn't have this obvious and nasty
bug:https://bugs.php.net/bug.php?id=46439
On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.Can't you make it also available as pecl extension, which could be built
on 5.4? This way people could enjoy the benefits of your work without
stable branch being disrupted and BC problems raised.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Sigh, I could have edited that better, but I think the apology came across
(:
This is still a thing worth fixing.
I do see now that at curl did introduce the @ craziness. So it is unfair
of me to single out PHP for introducing it. I'm not sure if the @ syntax is
a sneaky feature of the standard C API, but it's definitely a sneaky
feature of the command line utility.I did include a comment there when I first opened that bug report,
proposing a more appropriate and sustainable interface. Documentation
changes would make it possible to avoid the problem by looking carefully
for strange "gotchas" in the fine print - but not to actually submit a
value starting with a @, if, y'know, I wanted to do something crazy-nutty
like send arbitrary data legal in any other form submission (:Apologies for hijacking the discussion.
The '@' business does not come from libcurl. Native C libcurl
hi Tom,
For one, it is mapped to the libcurl constants and behavior.
Also this but report contains clear comment about this issue being a
documentation problem, contribution welcome :)If you consider it as something that should be changed, then please
feel free to add a comment there as well, or a patch :)But that's not really what we discuss here but the new code proposed
by Pierrick.Cheers,
I'd sure like a PHP extension that didn't have this obvious and nasty
bug:https://bugs.php.net/bug.php?id=46439
On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.Can't you make it also available as pecl extension, which could be
built
on 5.4? This way people could enjoy the benefits of your work without
stable branch being disrupted and BC problems raised.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Hi!
I'd sure like a PHP extension that didn't have this obvious and nasty bug:
This doesn't look good. Documentation does say the @ prefix exists, but
it has very high potential of creating security holes for unsuspecting
people. open_basedir would help limit the impact, but still it's not a
good thing. Any ideas on fixing it without breaking the BC?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I'd sure like a PHP extension that didn't have this obvious and
nasty bug:This doesn't look good. Documentation does say the @ prefix exists,
but
it has very high potential of creating security holes for unsuspecting
people. open_basedir would help limit the impact, but still it's not a
good thing. Any ideas on fixing it without breaking the BC?
Ouch.
Issue an E_NOTICE when it happens?
Add a new CURLOPT_FILEFIELDS that takes an array of the parameters
that are supposed to be files, so the ones that are expected to have
"@..." do not fire the E_NOTICE.
Issuing E_NOTICE is a BC, I suppose, but you'd think people would
appreciate an alert about a potential security threat...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
This doesn't look good. Documentation does say the @ prefix exists,
but
it has very high potential of creating security holes for unsuspecting
people. open_basedir would help limit the impact, but still it's not a
good thing. Any ideas on fixing it without breaking the BC?
Ouch.Issue an
E_NOTICEwhen it happens?Add a new CURLOPT_FILEFIELDS that takes an array of the parameters
that are supposed to be files, so the ones that are expected to have
"@..." do not fire the E_NOTICE.Issuing
E_NOTICEis a BC, I suppose, but you'd think people would
appreciate an alert about a potential security threat...
That would only trigger the notice when you transfer data beginning with
an @,
which would end up being only when finally attacked.
I'd make it need another option to make @ options work (eg.
CURLOPT_AT_TRANSFERS_FILES)
which default to false. Similar to SO_BROADCAST, where binding a socket
to a
broadcast address is not enough to send the packets there.
It is a BC break, but the current API is badly provided. I don't see a
way to
work around that. A one-line fix to get the previous not-too-used(?)
behavior back
seems as good as can be achieved.
It is also possible to make a completely new option API without those
problems,
and deprecate the old one, but that's still a BC break.
We could add a flag to disable the @ usage but I'm against having the
'@' usage disabled by default. This BC break would be in my opinion
too big.
An other solution would be to have something like (We will also have
to add the type and filename support to this solution so this is just
a first proposal) :
curl_setopt($curl_handle, CURLOPT_HTTPPOSTFIELDS, array(
'firstname' => 'pierrick',
'lastname' => array(CURL_FORMSTR, 'charron'),
'lastname' => array(CURL_FORMFILE, '/home/pierrick/picture.png')
);
Pierrick
Otherwise the safest way for people is to use http_build_query on
their parameter array.
Pierrick
Hi!
I'd sure like a PHP extension that didn't have this obvious and nasty bug:
This doesn't look good. Documentation does say the @ prefix exists, but it
has very high potential of creating security holes for unsuspecting people.
open_basedir would help limit the impact, but still it's not a good thing.
Any ideas on fixing it without breaking the BC?Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi all,
I know this topic was opened a long time ago, but I would like to get
it resolved before 5.5 got released.
One solution proposed by Richard Lynch was to add a new
CURLOPT_FILEFIELDS that takes an array of the parameters that are
supposed to be files, so the ones that are expected to have '@'. One
problem that we may have to deal with this solution is that the user
will have to add all the post params in 2 steps (first for the string
data and then for the files). Internally, libcurl only allow one call
to CURLOPT_HTTPPOST (second will override the first one), so it may
become unclear either the new data are appended, or overwrite the old
one.
An other solution proposed by Ángel González was to add a new option
to disable the '@' check, problem with this is that it will only
prevent uploading unwanted files if someone write something starting
with an '@', but it also disable completely the feature.
A last solution would be to something similar to libcurl curl_formadd
(this one could be added to the previous one so that the old way work
but there is a more secure way to do it) :
curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array(
'firstname' => 'pierrick',
'lastname' => array(CURLFORM_CONTENTS => 'charron'),
'lastname' => array(CURLFORM_FILENAME => 'name.png', CURLFORM_FILE
=> '/home/pierrick/picture.png', CURLFORM_CONTENTTYPE => 'image/jpg')
);
One thing we have to think about this solution is if at some point we
want to allow sending array via curl, will it conflict ?
Do someone have an other better idea ? Which one would you prefer and
see implemented ?
Thanks all for your inputs
Pierrick
Hi!
I'd sure like a PHP extension that didn't have this obvious and nasty bug:
This doesn't look good. Documentation does say the @ prefix exists, but it
has very high potential of creating security holes for unsuspecting people.
open_basedir would help limit the impact, but still it's not a good thing.
Any ideas on fixing it without breaking the BC?Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I know this topic was opened a long time ago, but I would like to get
it resolved before 5.5 got released.
I agree, it looks like a place where we could use improvement, current
API is kind of dangerous.
A last solution would be to something similar to libcurl curl_formadd
(this one could be added to the previous one so that the old way work
but there is a more secure way to do it) :curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array(
'firstname' => 'pierrick',
'lastname' => array(CURLFORM_CONTENTS => 'charron'),
'lastname' => array(CURLFORM_FILENAME => 'name.png', CURLFORM_FILE
=> '/home/pierrick/picture.png', CURLFORM_CONTENTTYPE => 'image/jpg')
);One thing we have to think about this solution is if at some point we
want to allow sending array via curl, will it conflict ?
I don't think we would allow sending arrays through curl, however
there's another problem - theoretically, if user can access the data you
put in $lastname variable, in many contexts it's not hard to put an
array there either - i.e. if you have a form that has element lastname
that posts to $lastname and then you do:
curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array(
'lastname' => $lastname,
/// etc.
Then you could also create a form that posts to lastname[filename] and
simulate this array too. So it's not a complete solution. I'm thinking
maybe using separate option for files and deprecating the current one
may be better idea. Unless somebody has even better solution :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
You're right the proposed implementation did not removed the issue but
was just changing the way to produce it and I agree that the most
secure way to do it would be as you suggested to add a separate option
but I see some issues that we will have.
Usually libcurl doesn't allow to call curl_easy_setopt with the same
option twice on the same easy handle, it will overwrite the data set
by the first call. php/cURL abstract multiple ways to send post data
all of them by the usage of CURLOPT_POSTFIELDS. When you set the
CURLOPT_POSTFIELD to an array using the php/curl api, php/curl will
internally use the CURLOPT_HTTPPOST option, and when you set the same
option to a string, it will call the CURLOPT_COPYPOSTFIELDS.
So first we will have to store the value of both CURLOPT_POSTFIELD and
CURLOPT_POSTFILEFIELD (or whatever we want to call it) so that we
always call CURLOPT_HTTPPOST once with the merge of the 2 options but
still, if someone do something like this
curl_setopt($ch, CURLOPT_POSTFIELD, 'foo=bar');
curl_setopt($ch, CURLOPT_POSTFILEFIELD, array('upload' => 'filename.jpg'));
This will not work because we need to use both CURLOPT_HTTPPOST and
CURLOPT_COPYPOSTFIELDS which are not compatible.
Idea on how we could solve this are welcome.
Thanks
Pierrick
Hi!
I know this topic was opened a long time ago, but I would like to get
it resolved before 5.5 got released.I agree, it looks like a place where we could use improvement, current
API is kind of dangerous.A last solution would be to something similar to libcurl curl_formadd
(this one could be added to the previous one so that the old way work
but there is a more secure way to do it) :curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array(
'firstname' => 'pierrick',
'lastname' => array(CURLFORM_CONTENTS => 'charron'),
'lastname' => array(CURLFORM_FILENAME => 'name.png', CURLFORM_FILE
=> '/home/pierrick/picture.png', CURLFORM_CONTENTTYPE => 'image/jpg')
);One thing we have to think about this solution is if at some point we
want to allow sending array via curl, will it conflict ?I don't think we would allow sending arrays through curl, however
there's another problem - theoretically, if user can access the data you
put in $lastname variable, in many contexts it's not hard to put an
array there either - i.e. if you have a form that has element lastname
that posts to $lastname and then you do:curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array(
'lastname' => $lastname,
/// etc.Then you could also create a form that posts to lastname[filename] and
simulate this array too. So it's not a complete solution. I'm thinking
maybe using separate option for files and deprecating the current one
may be better idea. Unless somebody has even better solution :)--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I'm thinking maybe the best solution is to have a new class - say,
CurlFile - and do this:
$file = new CurlFile("myface.png", "image/png");
curl_setopt($ch, CURLOPT_POSTFIELDS, array("foo" => "bar", "picture" =>
$file);
This would allow us to do two things:
- Protect ourselves from injection since you can not inject objects
(there's still a matter of serialized data, but this can be handled by
the class itself). - Support much more options in the file - e.g., right now it does not
support streams, but libcurl has CURLFORM_STREAM - maybe we could use
it, or maybe just read in the stream data and use it as CURLFORM_BUFFER.
Of course, that would not work for big files, but here we are able to
use much more options than with old @-based API.
Any holes in this idea? If not, I'll try to make an RFC for it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev smalyshev@sugarcrm.com wrote:
Hi!
I'm thinking maybe the best solution is to have a new class - say,
CurlFile - and do this:$file = new CurlFile("myface.png", "image/png");
curl_setopt($ch, CURLOPT_POSTFIELDS, array("foo" => "bar", "picture" =>
$file);
What I wonder about in this thread: If we struggle here why not take the full step and abstract curl details comletely away and provide something like pecl/http by default instead?
johannes
On Wed, Jan 2, 2013 at 8:39 AM, Johannes Schlüter
johannes@schlueters.de wrote:
Stas Malyshev smalyshev@sugarcrm.com wrote:
I'm thinking maybe the best solution is to have a new class - say,
CurlFile - and do this:$file = new CurlFile("myface.png", "image/png");
curl_setopt($ch, CURLOPT_POSTFIELDS, array("foo" => "bar", "picture" =>
$file);What I wonder about in this thread: If we struggle here why not take the
full step and abstract curl details comletely away and provide something
like pecl/http by default instead?
Personally I've always hated using the cURL API in PHP and would love
to see a solid implementation included by default, but I would guess
that the general consensus would be that it could/should be done in
user-land.
Anyone know if Guzzle (http://guzzlephp.org/) handles this? I know
it's a popular HTTP client for PHP and is included in the Amazon Web
Service SDK (https://github.com/aws/aws-sdk-php).
On Wed, Jan 2, 2013 at 4:39 PM, Johannes Schlüter johannes@schlueters.dewrote:
Stas Malyshev smalyshev@sugarcrm.com wrote:
Hi!
I'm thinking maybe the best solution is to have a new class - say,
CurlFile - and do this:$file = new CurlFile("myface.png", "image/png");
curl_setopt($ch, CURLOPT_POSTFIELDS, array("foo" => "bar", "picture" =>
$file);What I wonder about in this thread: If we struggle here why not take the
full step and abstract curl details comletely away and provide something
like pecl/http by default instead?johannes
I think that a more compact and easier-to-use API would be nice, but only
if we don't limit the current functionality.
So that should either provide everything that we have currently or only add
this as a separate interface, but keep the old one also.
my 2 cents
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
What I wonder about in this thread: If we struggle here why not take
the full step and abstract curl details comletely away and provide
something like pecl/http by default instead?
curl extension is widely used. So suggesting we just throw it away makes
no sense to me. We need to fix this deficiency in the API, since it may
break applications and expose users to hard-to-track security holes. As
for developing other extensions and adding pecl/http by default, this is
a valid issue but I'd rather discuss it separately.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
I think you're right using object is the safest way to do it safely.
It might look strange because there are no object at all in the
current extension and the procedural function will use in this
specific case an object but still we have to provide a safe way to do
it.
I also agree with Johannes, the php/curl api is not the easiest one to
use, mainly due to the number of available functionalities. pecl/http
is really a nicer api, and it is easier to work with but it don't
offer all the functionnalities libcurl do. Maybe Mike is planning to
add all of those ?
Pierrick
Hi!
I'm thinking maybe the best solution is to have a new class - say,
CurlFile - and do this:$file = new CurlFile("myface.png", "image/png");
curl_setopt($ch, CURLOPT_POSTFIELDS, array("foo" => "bar", "picture" =>
$file);This would allow us to do two things:
- Protect ourselves from injection since you can not inject objects
(there's still a matter of serialized data, but this can be handled by
the class itself).- Support much more options in the file - e.g., right now it does not
support streams, but libcurl has CURLFORM_STREAM - maybe we could use
it, or maybe just read in the stream data and use it as CURLFORM_BUFFER.
Of course, that would not work for big files, but here we are able to
use much more options than with old @-based API.Any holes in this idea? If not, I'll try to make an RFC for it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
That could work for people who don't have cURL built-in to their PHP
version, but otherwise create a symbol conflict.
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.Can't you make it also available as pecl extension, which could be built on
5.4? This way people could enjoy the benefits of your work without stable
branch being disrupted and BC problems raised.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I thought about it but I think it may confuse people to have two
different extensions with the same name, same interface, but one in
pecl and one in the core package (the difference between the 2
versions are not that big). Also as ilia mentioned if someone already
have the original version, they will have symbol conflicts. So I guess
we could just wait until PHP next unless someone have an other nice
solution which will not confuse people :)
Thanks all for your input.
Pierrick
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.Can't you make it also available as pecl extension, which could be built on
5.4? This way people could enjoy the benefits of your work without stable
branch being disrupted and BC problems raised.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I think waiting until PHP++ is probably the best approach. It would've
been nice to have the current libcurl version in 5.4.0, but since we're not
talking about any critical bug/security fixes, I don't think it's that big
a deal either way. So we may as well just sit on it for now.
--Kris
On Sun, Mar 11, 2012 at 8:55 PM, Pierrick Charron pierrick@webstart.frwrote:
I thought about it but I think it may confuse people to have two
different extensions with the same name, same interface, but one in
pecl and one in the core package (the difference between the 2
versions are not that big). Also as ilia mentioned if someone already
have the original version, they will have symbol conflicts. So I guess
we could just wait until PHP next unless someone have an other nice
solution which will not confuse people :)Thanks all for your input.
Pierrick
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work when it was already in RC phase.
The question now is should we include this new version in PHP5.4.1 or
should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
no feature break (AFAIK) so all the previous code should work as
expected. You'll find the list of new features attached and the last
code in the trunk branch.Can't you make it also available as pecl extension, which could be built
on
5.4? This way people could enjoy the benefits of your work without stable
branch being disrupted and BC problems raised.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227