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 smalys...@sugarcrm.comwrote:
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish my work
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
Stas,
That could work for people who don't have cURL built-in to their PHP
version, but otherwise create a symbol conflict.
On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish
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,
On 09/03/12 02:05, Adam Harvey wrote:
On 9 March 2012 00:11, Remi Collet r...@fedoraproject.org wrote:
Le 08/03/2012 09:03, Michael Wallner a écrit :
Sorry for the delay, but I already explained the issue in
the bug report: https://bugs.php.net/bug.php?id=61291
Thanks, for the explanation.
It'd be worse to keep the wrong behavior, providing as tiger what it is not.
What can be done is to add a tiger192,3-broken php5.4 hash for BC of
those which may have used the new one.
It's serious enough so I'd consider it a factor for a new minor in short
time, but not for setting in stone
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
Sigh, I could have edited that better, but I think the apology came across
(:
This is still a thing worth fixing.
On Sun, Mar 11, 2012 at 6:09 PM, Tom Boutell t...@punkave.com wrote:
I do see now that at curl did introduce the @ craziness. So it is unfair
of me to single out PHP for
On 11/03/12 22:55, Michael Wallner wrote:
wat?
The new hashes are correct. I'm awfully sorry that there has been so much
trouble with the tiger hashes, but it happened and cannot be undone.
Whops, sorry. I got confused on this thread.
Change the order of what I said, then. Let the correct
Hi!
I'd sure like a PHP extension that didn't have this obvious and nasty bug:
https://bugs.php.net/bug.php?id=46439
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
Ok, so it looks like we've had some decent conversation, but it has
started to tail off a bit. I'd normally draft an RFC at this point,
but it seems there's still some contention on how exactly the
implementation should work.
Personally, if we're going to go for any form of strict checking
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
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
13 matches
Mail list logo
