> To be clear, I *don't* mean SNI, I mean subjectAltName (SAN) validation.
Ah, apologies for the SNI/SAN confusion. However, I still cannot reproduce
this failure when verifying peers with certs utilizing the SAN extension. Could
you supply a code snippet demonstrating this failure?
On Thu, Sep
Daniel Lowrey wrote:
> This is incorrect. PHP has supported both the "SNI_enabled" and
> "SNI_server_name"
> SSL context options since 5.3. Anything older than 5.3 is not remotely
> worth worrying over. You can verify this for yourself using the following
> code:
To be clear, I *don't* mean SNI, I
On Sep 18, 2013 6:07 PM, "Tjerk Anne Meesters" wrote:
>
> On Thu, Sep 19, 2013 at 8:33 AM, Ángel González wrote:
>
> > On 16/09/13 15:58, Daniel Lowrey wrote:
> >
> >> More generally, PHP's stream encryption aspects are quite poorly
> >> documented. For example, https:// streams disable peer veri
> While we're on the topic, it's actually worse than that. Even if you
> turn peer validation and name checking on, PHP can't handle
> subjectAltNames in certificates, which causes quite a few failures.
This is incorrect. PHP has supported both the "SNI_enabled" and
"SNI_server_name"
SSL context o
I have run all the PHPT tests from the latest master test-pack against builds
with this patch on Windows (all versions 2008+):
I get the same failures I get from recent master builds. The patch doesn't
break anything on Windows.
You can get the PHP builds for Windows with this patch that I used
I would argue that LTR support is also inconsistent / not desired.
If I wrote:
$i = 0;
is_three($i = $i + 1, $i = $i + 1, $i = $i + 1);
I would certainly expect is_three to return false, but I would also expect
$i to contain three. php doesn't normally evaluate arguments lazily, it
would be wei
On Thu, Sep 19, 2013 at 8:33 AM, Ángel González wrote:
> On 16/09/13 15:58, Daniel Lowrey wrote:
>
>> More generally, PHP's stream encryption aspects are quite poorly
>> documented. For example, https:// streams disable peer verification by
>> default. While I understand that this is necessary to
Ángel González wrote:
> On 16/09/13 15:58, Daniel Lowrey wrote:
>> More generally, PHP's stream encryption aspects are quite poorly
>> documented. For example, https:// streams disable peer verification by
>> default. While I understand that this is necessary to provide the easiest
>> possible user
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's stream encryption aspects are quite poorly
documented. For example, https:// streams disable peer verification by
default. While I understand that this is necessary to provide the easiest
possible user experience for things like `file_
On Wed, Sep 18, 2013 at 4:19 PM, Michael Wallner wrote:
> Did the suggestion from UPGRADING.INTERNALS to use the php://input
> wrapper work out for you? Maybe I should add a comment inline...
>
Thank you for the tip.
It worked very well.
I read your patch didn't read UPGRADING.INTERNALS carefu
Am 18.09.2013 um 21:57 schrieb "Leigh" :
> On 18 September 2013 18:50, Bob Weinand wrote:
>> At least, from a technical point, evaluating LTR would require to change the
>> engine
>> (would be some more complex change as it would require to switch between
>> contexts
>> and being able to execute
On 18 September 2013 18:50, Bob Weinand wrote:
> At least, from a technical point, evaluating LTR would require to change the
> engine
> (would be some more complex change as it would require to switch between
> contexts
> and being able to execute the ZEND_SEND_VAL opcodes one by one
Feels lik
On 13/09/13 22:10, Lazy wrote:
Hello internals,
I'm trying to fix deadlock in an ancient php 5.2.17, php hangs on
internal libc lock.
From my understanding free is not safe to use in a signal handler, and
this seems to be the issue here.
No, it's not.
http://marc.info/?l=php-internals&m=1219
On Sep 18, 2013 10:53 AM, "Daniel Convissor" <
dani...@analysisandsolutions.com> wrote:
>
> Hi Bob:
>
> > It's now only for class/interface/trait, label and method names.
>
> Sure, that's not as bad.
>
> A bigger concern of mine is the added compatibility problem with new
> code possibly not being
On Wed, Sep 18, 2013 at 2:25 PM, Daniel Convissor <
dani...@analysisandsolutions.com> wrote:
> As someone who writes a lot of open source (and proprietary) code that
> gets run on machines that I have no control over, implementing this
> proposal will complicate my life. Every time I make a funct
>
> Hi Bob:
>
> > Well, that makes no sense. Then you just could say no to all new
> > language changes. Because it cannot be run on older versions.
>
> Allow me one last post to clarify. What I said is the cost in _this_
> case doesn't outweigh the advantages.
>
> As someone who writes a lot of
Am 18.9.2013 um 19:53 schrieb Daniel Convissor
:
> Hi Bob:
>
>> It's now only for class/interface/trait, label and method names.
>
> Sure, that's not as bad.
>
> A bigger concern of mine is the added compatibility problem with new
> code possibly not being able to run on older PHP versions. Th
On 18/09/2013 19:25, Daniel Convissor wrote:
> Allow me one last post to clarify. What I said is the cost in _this_
> case doesn't outweigh the advantages. As someone who writes a lot of
> open source (and proprietary) code that gets run on machines that I
> have no control over, implementing this
Hi Bob:
> Well, that makes no sense. Then you just could say no to all new
> language changes. Because it cannot be run on older versions.
Allow me one last post to clarify. What I said is the cost in _this_
case doesn't outweigh the advantages.
As someone who writes a lot of open source (and
Hi Bob:
> It's now only for class/interface/trait, label and method names.
Sure, that's not as bad.
A bigger concern of mine is the added compatibility problem with new
code possibly not being able to run on older PHP versions. That cost
seems greater than the benefit of some developers being a
Am 18.9.2013 um 18:09 schrieb Leigh :
> On 18 September 2013 14:50, Sean Coates wrote:
>> i.e. is_null($a, $b, $c) would be the same as is_null($a) && is_null($b)
>> && is_null($c)
>>
>> Note that this would not be semantically equivalent in this form, even if
>> `is_null()` did accept multiple p
On 18 September 2013 14:50, Sean Coates wrote:
> i.e. is_null($a, $b, $c) would be the same as is_null($a) && is_null($b)
> && is_null($c)
>
> Note that this would not be semantically equivalent in this form, even if
> `is_null()` did accept multiple parameters, because of the short-circuiting
> w
On Wed, Sep 18, 2013 at 04:33:50PM +0200, Julien Pauli wrote:
> One could use ltrace -l to trace library calls.
>
> On my laptop (Debian) :
>
> ltrace -l /usr/lib/x86_64-linux-gnu/libedit.so.2 php -a
>
> using_history(1, 38, 0x25000f, 712, 0x1087900) = 0
> Interactive s
Am Mittwoch, 18. September 2013 um 16:29 schrieb Ralph Schindler:
> http://news.php.net/php.internals/23254
>
> -ralph
>
> On 9/16/13 7:53 AM, Bob Weinand wrote:
> > Hi!
> >
> > This is the (official) RFC thread for the patch proposed in
> > http://php.markmail.org/message/7rn4mbwkbytqa3i
2013/9/18 Sean Coates :
>> Not a good idea IMHO: it would complexify the execution a lot, think about:
>
> To be clear, I wasn't proposing an alternative. I was just pointing out that
> function call semantics are not the same as conditional (short-circuit)
> semantics, as they appeared in the OP
2013/9/18 Chris London :
> I like the naming convention of are_*. For me personally it isn't directly
> intuitive that the multiple parameters of is_* would be compared with an &&
> and not an ||.
isset() already operates that way, keeping "is_" and implementing it
as originally proposed by Leigh
> Not a good idea IMHO: it would complexify the execution a lot, think about:
To be clear, I wasn't proposing an alternative. I was just pointing out that
function call semantics are not the same as conditional (short-circuit)
semantics, as they appeared in the OP.
S
--
PHP Internals - PHP Ru
2013/9/18 Sean Coates :
>> i.e. is_null($a, $b, $c) would be the same as is_null($a) && is_null($b)
>> && is_null($c)
>
> Note that this would not be semantically equivalent in this form, even if
> `is_null()` did accept multiple parameters, because of the short-circuiting
> with `&&`:
>
>
> fun
On Wed, Sep 18, 2013 at 4:20 PM, Alain Williams wrote:
> On Wed, Sep 18, 2013 at 04:13:39PM +0200, Remi Collet wrote:
> > Le 18/09/2013 16:04, Alain Williams a écrit :
> >
> > > What is needed is for this to NOT be called if the standard output is
> not
> > > connected to a tty.
> >
> > From your
http://news.php.net/php.internals/23254
-ralph
On 9/16/13 7:53 AM, Bob Weinand wrote:
Hi!
This is the (official) RFC thread for the patch proposed in
http://php.markmail.org/message/7rn4mbwkbytqa3ig
https://wiki.php.net/rfc/keywords_as_identifiers
Any feedback about the RFC or the implement
On Wed, Sep 18, 2013 at 04:13:39PM +0200, Remi Collet wrote:
> Le 18/09/2013 16:04, Alain Williams a écrit :
>
> > What is needed is for this to NOT be called if the standard output is not
> > connected to a tty.
>
> From your previous message:
>
> > ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {
Le 18/09/2013 16:04, Alain Williams a écrit :
> What is needed is for this to NOT be called if the standard output is not
> connected to a tty.
>From your previous message:
> ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
> ...}) = 0
> ioctl(0, SNDCTL_TMR_STOP or
On Tue, Sep 17, 2013 at 08:28:58AM +0200, Remi Collet wrote:
>
> Please... don't rely, for distro packaged PHP on configure option listed
> in phpinfo report [1].
>
> > Additional Modules
> >
> > Module Name
> > readline
>
> readline extension doesn't use readline library (under inc
I like the naming convention of are_*. For me personally it isn't directly
intuitive that the multiple parameters of is_* would be compared with an &&
and not an ||.
On Wed, Sep 18, 2013 at 7:50 AM, Sean Coates wrote:
> > i.e. is_null($a, $b, $c) would be the same as is_null($a) && is_null($b)
> i.e. is_null($a, $b, $c) would be the same as is_null($a) && is_null($b)
> && is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with `&&`:
Am 18.09.2013 um 14:30 schrieb "Nicolas Grekas" :
> Hi Bob, thanks for the RFC!
>
> For those of us that use token_get_all(), will the newly allowed token
> appear as T_STRING or as T_%KEYWORD%?
> May I suggest you add a word about it in the RFC?
>
> As Ryan pointed out in the other thread, a T_
On 18 September 2013 12:15, Igor Wiedler wrote:
>
> for is_* functions, this could easily be done with a higher-order "every"
> function. You pass a predicate and an array of values. It returns a boolean.
>
> Example:
>
> if (!every('is_int', $numbers)) {
> throw new \Inva
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov wrote:
> Hi internals!
>
> This is a spinoff from the variadics thread. Quoting Stas:
>
> > I also think this:
> > public function query($query, ...$params)
> > public function query(...$params)
> > should be legal too.
>
> This is a general
Hi Bob, thanks for the RFC!
For those of us that use token_get_all(), will the newly allowed token
appear as T_STRING or as T_%KEYWORD%?
May I suggest you add a word about it in the RFC?
As Ryan pointed out in the other thread, a T_%KEYWORD% has a high chance to
break existing documentation gener
> function doStuffWithNumbers(...$numbers) {
> if (!is_int(...$numbers)) {
> throw new InvalidArgumentException('blah');
> ...
>
> Thoughts?
Returning bool in this case will make it impossible to respond with a
meaningful error message. Which of the provided arguments !is_int()?
Inst
2013/9/18 Igor Wiedler
> On Sep 18, 2013, at 11:53 AM, Leigh wrote:
>
> > Hi Internals.
> >
> > How do you feel about expanding the is_* functions to accept multiple
> > parameters similar to the way isset() already does?
> >
> > ...
> >
> > Thoughts?
>
> For isset() there is a good reason to do
Am 18.09.2013 um 09:28 schrieb "David Neilsen" :
> "missing any real-world examples of why it might be useful"
>
> One thing the I have run across in making my libraries, is the not being
> able to call a function `default`.
>
> I use the chainable getter/setter in one syntax a lot (a la jQuery).
On Sep 18, 2013, at 11:53 AM, Leigh wrote:
> Hi Internals.
>
> How do you feel about expanding the is_* functions to accept multiple
> parameters similar to the way isset() already does?
>
> ...
>
> Thoughts?
For isset() there is a good reason to do this, because the var might not exist
at a
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov wrote:
> Hi internals!
>
> This is a spinoff from the variadics thread. Quoting Stas:
>
> > I also think this:
> > public function query($query, ...$params)
> > public function query(...$params)
> > should be legal too.
>
> This is a general
On Wednesday, September 18, 2013 at 12:53 PM, Leigh wrote:
> Hi Internals.
>
> How do you feel about expanding the is_* functions to accept multiple
> parameters similar to the way isset() already does?
>
> From the manual: "If multiple parameters are supplied then isset() will
> return TRUE only
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
>From the manual: "If multiple parameters are supplied then isset() will
return TRUE only if all of the parameters are set. Evaluation goes from
left to right an
*Should have been !== null
On Wed, Sep 18, 2013 at 7:27 PM, David Neilsen wrote:
> "missing any real-world examples of why it might be useful"
>
> One thing the I have run across in making my libraries, is the not being
> able to call a function `default`.
>
> I use the chainable getter/setter
"missing any real-world examples of why it might be useful"
One thing the I have run across in making my libraries, is the not being
able to call a function `default`.
I use the chainable getter/setter in one syntax a lot (a la jQuery). Hence
when I have a class with a property named default, and
Hi Yasuo!
On 17 September 2013 21:17, Yasuo Ohgaki wrote:
> Hi all,
>
> SG(request_info).post_data/raw_post_data is removed and modules supposed to
> read it from stream on master.
Did the suggestion from UPGRADING.INTERNALS to use the php://input
wrapper work out for you? Maybe I should add a
49 matches
Mail list logo
