Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

[Michael Wallner]

On 22 Apr 2015 10:27, "Alexander Moskalev"  wrote:
>
> Thanks to all for feedback!
>
> Let's try to integrate new feature to old class.
> We have constructor in CURLFile with one required parameter: $filename .
> To avoid BC break we cannot replace this parameter. So  I suggest to do it
> optional and add setBuffer() method.
>
> So we can create CURLFile with empty parameters in constructor and fill it
> with setters.
> Have two more questions:
> 1) If we not fill all options or fille not compatible options, when we
must
> throw error? ? And what level of this error? (Sorry, I'm just php coder
and
> know about C language and php source so little)
> For file from disk(or other source) required $filename. For file from
> buffer required $buffer and $postname.
> 2) Curently CURLFile cannot be unserialized, because it contains $filename
> (see source code). How it compatible with our dicussion?
>

Why not a ctor as in:

function __construct ($filename, $buffer = null) {
if (isset ($ buffer)) {
// use $ buffer
} else {
// use file contents
}
}

The file name parameter can be of use anyway for posted file contents from
buffer.

Cheers,
Mike

Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

[Alexey Zakhlestin]

> On 23 Apr 2015, at 11:59, Michael Wallner  wrote:
> 
> Why not a ctor as in:
> 
> function __construct ($filename, $buffer = null) {
>if (isset ($ buffer)) {
>// use $ buffer
>} else {
>// use file contents
>}
> }
> 
> The file name parameter can be of use anyway for posted file contents from
> buffer.

Looks good! So, it work like this (+ error handling)

function __construct($filename, $buffer = null)
{
$this->filename = $filename;

if (is_null($buffer)) {
$this->data = file_get_contents($filename);
} else {
$this->data = buffer;
}
}



А.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[Lester Caine]

On 23/04/15 06:50, christopher jones wrote:
> Yes, we do recommend using OCI8 over PDO_OCI.  This is partly due to
> some inherent design and performance weaknesses of the overall PDO
> architecture.
> 
> So, lets not mark PDO_OCI as dead just yet.

It's nice to hear that it's not only the pdo_firebird driver that is
restricted by PDO. Which why I was asking for a general review on the
situation on database access.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

чт, 23 Апр 2015, 13:00, Lester Caine :

On 23/04/15 06:50, christopher jones wrote:
> Yes, we do recommend using OCI8 over PDO_OCI.  This is partly due to
> some inherent design and performance weaknesses of the overall PDO
> architecture.
>
> So, lets not mark PDO_OCI as dead just yet.

It's nice to hear that it's not only the pdo_firebird driver that is
restricted by PDO. Which why I was asking for a general review on the
situation on database access.

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


 Hello,

I can definetly make a case that PDO restricts MySQL too. It lacks a lot of
functionality comparing to mysqli. I also found out recently that you can't
have a named param appear in a query more than once (an OR case, where 2
fields are compared against sma e value). The more you work, the more you
understand that PDO was a hype, that never got finished and got almost
abandoned.

Re: [PHP-DEV] Re: PDO Oracle driver

[Lester Caine]

On 23/04/15 11:22, Arvids Godjuks wrote:
> чт, 23 Апр 2015, 13:00, Lester Caine :
> 
> On 23/04/15 06:50, christopher jones wrote:
>> > Yes, we do recommend using OCI8 over PDO_OCI.  This is partly due to
>> > some inherent design and performance weaknesses of the overall PDO
>> > architecture.
>> >
>> > So, lets not mark PDO_OCI as dead just yet.
> It's nice to hear that it's not only the pdo_firebird driver that is
> restricted by PDO. Which why I was asking for a general review on the
> situation on database access.
> 
> I can definetly make a case that PDO restricts MySQL too. It lacks a lot of
> functionality comparing to mysqli. I also found out recently that you can't
> have a named param appear in a query more than once (an OR case, where 2
> fields are compared against sma e value). The more you work, the more you
> understand that PDO was a hype, that never got finished and got almost
> abandoned.

Now that is that sort of feedback I was not expecting ... I don't use
MySQL so to see that it has some inherent problems with PDO as most of
the other databases is news. I think PDO is probably now too embedded in
some projects to roll back but certainly it's limitations need to be
better documented? Some of it's restrictions can not be solved by
changes to the code, they are incompatible with the base format, but
there is nothing explaining that.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[Matteo Beccati]

Hello,

On 23/04/2015 12:22, Arvids Godjuks wrote:

чт, 23 Апр 2015, 13:00, Lester Caine :
It's nice to hear that it's not only the pdo_firebird driver that is
restricted by PDO. Which why I was asking for a general review on the
situation on database access.

I can definetly make a case that PDO restricts MySQL too. It lacks a lot of
functionality comparing to mysqli. I also found out recently that you can't
have a named param appear in a query more than once (an OR case, where 2
fields are compared against sma e value). The more you work, the more you
understand that PDO was a hype, that never got finished and got almost
abandoned.


It is always nice to hear people complaining and bashing things just for 
the sake of it.


Unhappy about something? Well, fix it. Or hire someone to fix it. 
Connect with others and collectively hire someone to fix it. Create 
proper bug reports and try to find someone capable and willing to help. 
Whatever, but please do something useful.


Guess what? Tirelessly whining about things being inherently broken 
won't magically fix them.



Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[Christoph Becker]

Lester Caine wrote:

> On 23/04/15 11:22, Arvids Godjuks wrote:
>
>> I can definetly make a case that PDO restricts MySQL too. It lacks a lot of
>> functionality comparing to mysqli. I also found out recently that you can't
>> have a named param appear in a query more than once (an OR case, where 2
>> fields are compared against sma e value). The more you work, the more you
>> understand that PDO was a hype, that never got finished and got almost
>> abandoned.
> 
> Now that is that sort of feedback I was not expecting ... I don't use
> MySQL so to see that it has some inherent problems with PDO as most of
> the other databases is news. I think PDO is probably now too embedded in
> some projects to roll back but certainly it's limitations need to be
> better documented? Some of it's restrictions can not be solved by
> changes to the code, they are incompatible with the base format, but
> there is nothing explaining that.

The introduction man page on PDO[1] states:

| PDO does not provide a database abstraction; it doesn't rewrite SQL
| or emulate missing features. You should use a full-blown abstraction
| layer if you need that facility.

[1] 

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

[Alexander Moskalev]

Because currently CURLFile have this constructor:
public __construct  (
string $filename [, string $mimetype [, string $postname ]] )

And we cannot replace this arguments to avoid BC break.

2015-04-23 11:59 GMT+03:00 Michael Wallner :

>
> On 22 Apr 2015 10:27, "Alexander Moskalev"  wrote:
> >
> > Thanks to all for feedback!
> >
> > Let's try to integrate new feature to old class.
> > We have constructor in CURLFile with one required parameter: $filename .
> > To avoid BC break we cannot replace this parameter. So  I suggest to do
> it
> > optional and add setBuffer() method.
> >
> > So we can create CURLFile with empty parameters in constructor and fill
> it
> > with setters.
> > Have two more questions:
> > 1) If we not fill all options or fille not compatible options, when we
> must
> > throw error? ? And what level of this error? (Sorry, I'm just php coder
> and
> > know about C language and php source so little)
> > For file from disk(or other source) required $filename. For file from
> > buffer required $buffer and $postname.
> > 2) Curently CURLFile cannot be unserialized, because it contains
> $filename
> > (see source code). How it compatible with our dicussion?
> >
>
> Why not a ctor as in:
>
> function __construct ($filename, $buffer = null) {
> if (isset ($ buffer)) {
> // use $ buffer
> } else {
> // use file contents
> }
> }
>
> The file name parameter can be of use anyway for posted file contents from
> buffer.
>
> Cheers,
> Mike
>



-- 
With regards, Alexander Moskalev
ir...@irker.net
ir...@php.net
a.moska...@corp.badoo.com

Re: [PHP-DEV] Re: PDO Oracle driver

[Lester Caine]

On 23/04/15 11:54, Matteo Beccati wrote:
> Guess what? Tirelessly whining about things being inherently broken
> won't magically fix them.

Neither will throwing money at PDO. It is restricted to a single active
transaction so can't handle cross database activity. One has to switch
back to the generic drivers. So one ends up with having to run both anyway.

Christoph SQL abstraction is a separate matter. While it IS one reason
PDO is not a solution to cross database working, there are other
problems at the data layer.

PDO is not a complete solution even to the data layer abstraction, so
does it actually provide any value to PHP? Would it not be better to
re-address the 'problem' and come up with a better solution?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] clear_env default in php-fpm

[Mathieu Rochette]

Hello,

A |clear_env |settings had been added in php 5.4 with default |clear_env 
= yes| to avoid BC I imagine. With service such as heroku or with 
docker, and followinf the 12 factor principles, configuration from other 
services are defined with env vars. What do you think about changing the 
default to |clear_env = no| ? It would also match the behavior of using 
php with apache mod. Is it possible for 7.0 ? I don't know if it's too 
late for this kind of change but I guess that if it's not for 7.0 it 
would have to wait for 8.0 isn't it ?


I didn't find much information about this change (even finding about 
|clear_env| is not that easy when search for "php fpm env var") so I 
don't know if there is others reason than BC.


thank you

--
Mathieu Rochette

[PHP-DEV] Refund on order 204-2374256-3787503

[Amazon.co.uk]

Dear Customer,

Greetings from Amazon.co.uk.

We are writing to confirm that we are processing your refund in the amount of 
£4.89 for your
Order 204-2374256-3787503.

This amount has been credited to your payment method and will appear when your 
bank has processed it.

This refund is for the following item(s):

Item: Beautiful Bitch
Quantity: 1
ASIN: 1476754144
Reason for refund: Customer return

The following is the breakdown of your refund for this item:

Item Refund: £4.89

Your refund is being credited as follows:

GC: £4.89

These amounts will be returned to your payment methods within 5 business days.

The amount credited to your Gift Card balance should be automatically applied 
to your next eligible
order on our website.

Have an issue with your refund, or a question about our refund policy?
Visit our Help section for more information:

http://www.amazon.co.uk/gp/help/customer/display.html?nodeId=1161010

Please note: The credit note for this transaction is attached to this e-mail 
and to open, you will
need Adobe Reader. If you do not have an Adobe Reader, please visit the 
following link to download
it: http://get.adobe.com/reader/

This credit note is the detailed breakdown of the refund showing the item(s), 
delivery costs and
associated VAT for each item. This credit note is largely applicable to 
business customers who
should retain it for accounting purposes. It’s not possible to redeem or use 
the credit
note number from this credit note towards an order. Visit our Help pages for 
more information on
refunds.

Thank you for shopping at Amazon.co.uk.

Sincerely,

Amazon.co.uk Customer Service
http://www.amazon.co.uk


Note: this e-mail was sent from a notification-only e-mail address that cannot 
accept incoming e-mail.
Please do not reply to this message.

An advanced electronic signature has been attached to this electronic credit 
note. To add the certificate
as a trusted certificate, please follow these instructions:
1. Click on the 'Signature Panel' in the upper right corner
2. Expand the drop-down in the newly opened Signatures menu, expand the 
'Signature Details' drop-down and
   click 'Certificate Details'
3. In the Certificate Viewer box click on the 'Trust' tab, click 'Add To 
Trusted Certificates' and then
   click OK
4. In the Import Contact Settings box, ensure that 'Use this certificate as a 
trusted root' is selected,
   click OK, and then click OK again

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: ***SPAM*** [PHP-DEV] Refund on order 204-2374256-3787503

[Lester Caine]

On 23/04/15 13:46, Amazon.co.uk wrote:
> We are writing to confirm that we are processing your refund in the amount of 
> £4.89 for your
> Order 204-2374256-3787503.

Curious phishing attempt ... seems to have forgotten the aim? Or was
there something stripped by the mail list?

(Some hit PEAR list as well)

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: ***SPAM*** [PHP-DEV] Refund on order 204-2374256-3787503

[Arvids Godjuks]

2015-04-23 15:56 GMT+03:00 Lester Caine :

> On 23/04/15 13:46, Amazon.co.uk wrote:
> > We are writing to confirm that we are processing your refund in the
> amount of £4.89 for your
> > Order 204-2374256-3787503.
>
> Curious phishing attempt ... seems to have forgotten the aim? Or was
> there something stripped by the mail list?
>
> (Some hit PEAR list as well)
>
> --
> Lester Caine - G8HFL
>
>
Curiously enough - it's a book...
Someone used lists email while ordering a book?...

Anyway, I have to give points for entertainment it just brought :)

Re: [PHP-DEV] Re: ***SPAM*** [PHP-DEV] Refund on order 204-2374256-3787503

[Rowan Collins]

Lester Caine wrote on 23/04/2015 13:56:

On 23/04/15 13:46, Amazon.co.uk wrote:

We are writing to confirm that we are processing your refund in the amount of 
£4.89 for your
Order 204-2374256-3787503.

Curious phishing attempt ... seems to have forgotten the aim? Or was
there something stripped by the mail list?

(Some hit PEAR list as well)


Yep, attachment stripping:

> Please note: The credit note for this transaction is attached to this 
e-mail and to open, you will need Adobe Reader.


There seems to be a whole load of PDF-borne malware around at the moment. :(


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

My view is that this really needs a good discussion and regardless of the
desicions made - resource allocation to move it forward.
Whatever the intent was originally for the PDO and and regardless of what
the docs say about it, as Christoph has linked and quoted, the reality is
PDO is everywhere. Doctrine? Based on PDO. Yii 1/2 ActiveRecord? PDO.
Laravel's Eloquent ? PDO again. You get the picture.
It's all ponies and rainbows untill you start doing something besides the
basic typical website (wich I tend to get more and more nowdays, as my
experience growed to a certain level and projects started to get big and
serious). At that point you just start to hit those annoyances with the
PDO. Thank god I didn't hit a really big snag yet, but it caused me a few
headaces and ugly workarounds.  I just can't write a standalone script with
a different driver (mysqli) in a big application - chances are I need that
applications AR models, it's bussiness logic and so on.
I even once had to do a major server upgrade just because of the bug in PDO
- well, I have to confess it was due anyway in a year's time frame, but
works great as illustration to it's problems and how much attention it gets.
A lack of basic ping function: I had to emulate it by sending a "SELECT
NOW()" request every 30 seconds and make sure my MySQL server has a
connection timeout of atleast 60 seconds, so a long running CLI script can
do it's job. I do not remember why, but I was unable to reconnect after
loosing the connection - it was a while ago and may have changed since
then. Still, left a certain impression.

Anyway, not to dwell on my ramblings, the situation needs a long overdue
discussion. A dealogue with the respective database developers would be
helpfull, if not instrumental, in changing things around.


Answering to Matteo Beccati's email:
Not everyone has C knowlage (nor leared it at any point in their career).
On top of that it's databases we are talking about - how many people are
able to develop proper drivers for DB's?
And not everyone has the funding to sponsor things like these. I certanly
nor have the money, nor I know of anyone who I could give the task to do
it. I'm from small Baltic country - I do not think we have any brains here
that are up to the challenge, atleast I have no idea of anyone even remotly
in this country despite my over 10 years in webdev.
My thinking is that things like these have to be spearheaded by the
respective database developers with the help of the PHP core team and the
community.

Re: [PHP-DEV] Re: PDO Oracle driver

[Pierre Joye]

On Apr 23, 2015 8:45 PM, "Arvids Godjuks"  wrote:
>
> My view is that this really needs a good discussion and regardless of the
> desicions made - resource allocation to move it forward.
> Whatever the intent was originally for the PDO and and regardless of what
> the docs say about it, as Christoph has linked and quoted, the reality is
> PDO is everywhere. Doctrine? Based on PDO. Yii 1/2 ActiveRecord? PDO.
> Laravel's Eloquent ? PDO again. You get the picture.

Not being in core is an issue with PDO. Sqlsrv is in pecl, maintained, and
support both "native" and PDO.

Re: [PHP-DEV] Re: PDO Oracle driver

[Lester Caine]

On 23/04/15 14:45, Arvids Godjuks wrote:


> My thinking is that things like these have to be spearheaded by the
> respective database developers with the help of the PHP core team and the
> community.

I am still reliant on ADOdb and have on a number of occasions back
ported to that where projects have 'upgraded' to PDO. I still see no
reason for everybody to be reinventing the wheel when we HAD a perfectly
practical solution 10+ years ago. It would be nice to restore it's
speed-up extension once again and certainly I will be ensuring
everything works with PHP7. There are a number of other layers, but all
PDO seems to have done is fragment the code base with everybody doing
their own thing SQL abstraction wise, rather than our producing a
standard such as ADOdb provides?

The good thing is that replacing PDO with something else at the base
level is not a major exercise as most frameworks don't call it direct
anyway :)

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

2015-04-23 17:02 GMT+03:00 Pierre Joye :

>
> On Apr 23, 2015 8:45 PM, "Arvids Godjuks" 
> wrote:
> >
> > My view is that this really needs a good discussion and regardless of the
> > desicions made - resource allocation to move it forward.
> > Whatever the intent was originally for the PDO and and regardless of what
> > the docs say about it, as Christoph has linked and quoted, the reality is
> > PDO is everywhere. Doctrine? Based on PDO. Yii 1/2 ActiveRecord? PDO.
> > Laravel's Eloquent ? PDO again. You get the picture.
>
> Not being in core is an issue with PDO. Sqlsrv is in pecl, maintained, and
> support both "native" and PDO.
>
I do not think it's a "in core" vs "in pecl" issue at all. It's the fact
that that it is data objects and it was new back in the day - the adoption
of it was lightning fast. It was easy to make an abstraction over it, it
fit to major patterns, like AR, like a glove.
Besides, installing DB modules for PHP under ubuntu is done by hand - it's
not built into the "php5" package.

Re: [PHP-DEV] clear_env default in php-fpm

[Dan Ackroyd]

On 23 April 2015 at 12:13, Mathieu Rochette  wrote:

> I didn't find much information about this change (even finding about
> |clear_env| is not that easy when search for "php fpm env var") so I don't
> know if there is others reason than BC.

It looks like it wasn't discussed that much. The PR has a brief conversation:
https://github.com/php/php-src/pull/598


> What do you think about changing the default to
> |clear_env = no| ?


For 'Container like' hosting where the application being deployed is
owned by the company doing the deploying, and all the configuration is
done automatically and no humans ever touch the machine, having
'clear_env' default to 'no' would make sense.

For, shared hosting and other places where the application being
deployed might not be owned by the same people that control the
server, having 'clear_env' default to 'no' sounds like a security
problem, as it would allow the potential for people to modify the env
settings, which they can't currently do.

Wouldn't it make more sense just to ask Heroku (or whichever container
provider someone is using) to change the setting in the version of PHP
that they provide. For the general release of PHP, unless someone can
demonstrate how it wouldn't be a security problem, continuing to
default to the current secure setting sounds sensible to me.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[Pierre Joye]

On Apr 23, 2015 9:14 PM, "Arvids Godjuks"  wrote:
>
> 2015-04-23 17:02 GMT+03:00 Pierre Joye :
>>
>>
>> On Apr 23, 2015 8:45 PM, "Arvids Godjuks" 
wrote:
>> >
>> > My view is that this really needs a good discussion and regardless of
the
>> > desicions made - resource allocation to move it forward.
>> > Whatever the intent was originally for the PDO and and regardless of
what
>> > the docs say about it, as Christoph has linked and quoted, the reality
is
>> > PDO is everywhere. Doctrine? Based on PDO. Yii 1/2 ActiveRecord? PDO.
>> > Laravel's Eloquent ? PDO again. You get the picture.
>>
>> Not being in core is an issue with PDO. Sqlsrv is in pecl, maintained,
and support both "native" and PDO.
>
> I do not think it's a "in core" vs "in pecl" issue at all. It's the fact
that that it is data objects and it was new back in the day - the adoption
of it was lightning fast. It was easy to make an abstraction over it, it
fit to major patterns, like AR, like a glove.
> Besides, installing DB modules for PHP under ubuntu is done by hand -
it's not built into the "php5" package.

Just like many other. Not being in core brings actually more flexibility to
the devs

Re: [PHP-DEV] Re: PDO Oracle driver

[Lester Caine]

On 23/04/15 18:18, Pierre Joye wrote:
> Just like many other. Not being in core brings actually more flexibility to
> the devs

Pierre are you coming around to the idea that a more modular approach to
PHP packages may actually be better? Just being able to select what we
use rather than all of the other 'core' packages would be nice ;)

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] clear_env default in php-fpm

[Mathieu Rochette]

On 04/23/2015 05:11 PM, Dan Ackroyd wrote:

On 23 April 2015 at 12:13, Mathieu Rochette  wrote:


I didn't find much information about this change (even finding about
|clear_env| is not that easy when search for "php fpm env var") so I don't
know if there is others reason than BC.

It looks like it wasn't discussed that much. The PR has a brief conversation:
https://github.com/php/php-src/pull/598



What do you think about changing the default to
|clear_env = no| ?


For 'Container like' hosting where the application being deployed is
owned by the company doing the deploying, and all the configuration is
done automatically and no humans ever touch the machine, having
'clear_env' default to 'no' would make sense.

For, shared hosting and other places where the application being
deployed might not be owned by the same people that control the
server, having 'clear_env' default to 'no' sounds like a security
problem, as it would allow the potential for people to modify the env
settings, which they can't currently do.
What do you mean? As I understand it, clear_env = no, would give users 
read access to env variables, not the ability to modify it. am I wrong?


Wouldn't it make more sense just to ask Heroku (or whichever container
provider someone is using) to change the setting in the version of PHP
that they provide. For the general release of PHP, unless someone can
demonstrate how it wouldn't be a security problem, continuing to
default to the current secure setting sounds sensible to me.
I'm not a security expert so I don't know how it could be proven. the 
best argument I have is that apache php mod does not AFAIK clears env 
and everything seems fine


cheers
Dan

thank you for your reply,

--
Mathieu Rochette


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[Benjamin Eberlei]

On Thu, Apr 23, 2015 at 3:45 PM, Arvids Godjuks 
wrote:

> PDO is everywhere. Doctrine? Based on PDO.


You can use mysqli, oci8 or sqlsrv for example without problems in Doctrine.

Exposing some of the internal api of PDO as php functions (SQL Parser) I
would bet it is possible to reimplement PDO in PHP code using mysqli etc..
as "drivers".

I think we could discuss going that road as well and we could save
ourselves maintaining some thousands of lines of C code.

Re: [PHP-DEV] Re: PDO Oracle driver

[Arvids Godjuks]

2015-04-24 4:42 GMT+03:00 Benjamin Eberlei :

> On Thu, Apr 23, 2015 at 3:45 PM, Arvids Godjuks 
> wrote:
>
> > PDO is everywhere. Doctrine? Based on PDO.
>
>
> You can use mysqli, oci8 or sqlsrv for example without problems in
> Doctrine.
>
> Exposing some of the internal api of PDO as php functions (SQL Parser) I
> would bet it is possible to reimplement PDO in PHP code using mysqli etc..
> as "drivers".
>
> I think we could discuss going that road as well and we could save
> ourselves maintaining some thousands of lines of C code.
>

May I question the sanity of the words written in this email? :D (it's a
joke).

The whole point of mysqlnd drivers and other improvements was to cut down
on data copying, improving performance and doing a lot of other stuff.
Moving PDO to a PHP implementation will kill it all: preformance will
suffer, memory usage will skyrocket, dealing with charsets - I don't even
wana pretend I understand how to deal with that part in a proper fasion.
Doesn't it require access to internal PHP api's to do a lot of what PDO and
other native drivers do?
Well, the Zephyr could pitch in here, MAYBE, depending on how good it
actually is and what it can do, but still, it feels more like a cruch to me.