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 wrote:
> Hi!
>
>
> I wanted to make this new version available in PHP5.4 but
>> unfortunately I did finish my work when it was already
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
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 wrote:
> Hi!
>
>
>> I wanted to make this new version available in PHP5.4 but
>> unfortunately I did finish my work when it w
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, o
On 09/03/12 02:05, Adam Harvey wrote:
> On 9 March 2012 00:11, Remi Collet 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.
> I'm still co
> 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
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 wrote:
> 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
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 help
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
(meani
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 w
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 S
I caused this situation myself by not explicitly differentiating between
the default charset for the internal htmlspecialchars() and
htmlentities() functions and the output charset directive ini directive
default_charset.
The idea behind the default_charset ini directive was to act as the
charset
On Mon, Mar 12, 2012 at 2:49 PM, Rasmus Lerdorf wrote:
> I caused this situation myself by not explicitly differentiating between
> the default charset for the internal htmlspecialchars() and
> htmlentities() functions and the output charset directive ini directive
> default_charset.
>
> The idea
15 matches
Mail list logo
