Hi.
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.
My use case is that the provider we are currently using does not allow us
to have our own INI file, just the additional directory, and there is no
way to differentiate between a CLI and a FAST-CGI setup in the additional
directory.
The patch allows [SAPI=xxx] sections and they operate in a very similar way
to the [HOST] and [PATH] sections.
Please can this be considered for inclusion into PHP at some stage.
Regards,
Richard Quadling.
Hi.
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.My use case is that the provider we are currently using does not allow us
to have our own INI file, just the additional directory, and there is no
way to differentiate between a CLI and a FAST-CGI setup in the additional
directory.The patch allows [SAPI=xxx] sections and they operate in a very similar
way to the [HOST] and [PATH] sections.Please can this be considered for inclusion into PHP at some stage.
Regards,
Richard Quadling.
Anyone got the time to look at this?
--
Richard Quadling
Twitter : @RQuadling
2013/11/16 Richard Quadling rquadling@gmail.com
Hi.
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.My use case is that the provider we are currently using does not allow us
to have our own INI file, just the additional directory, and there is no
way to differentiate between a CLI and a FAST-CGI setup in the additional
directory.The patch allows [SAPI=xxx] sections and they operate in a very similar way
to the [HOST] and [PATH] sections.Please can this be considered for inclusion into PHP at some stage.
Regards,
Richard Quadling.
Hi,
Just my 2 cents, but that sounds more like an issue with your
provider/hoster and not with PHP. I always thought of the additional
php.ini as a way to change some details and not a way to set up the whole
runtime. Especially when a user has write access to that file it seems to
me also an security issue, when PHP allows to set/change critical settings
there.
tl;dr: There is probably a reason, why your provider doesn't allow you to
change php.ini settings directly.
Regards,
Sebastian
2013/11/16 Richard Quadling rquadling@gmail.com
Hi.
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.My use case is that the provider we are currently using does not allow us
to have our own INI file, just the additional directory, and there is no
way to differentiate between a CLI and a FAST-CGI setup in the additional
directory.The patch allows [SAPI=xxx] sections and they operate in a very similar
way
to the [HOST] and [PATH] sections.Please can this be considered for inclusion into PHP at some stage.
Regards,
Richard Quadling.
Hi,
Just my 2 cents, but that sounds more like an issue with your
provider/hoster and not with PHP. I always thought of the additional
php.ini as a way to change some details and not a way to set up the whole
runtime. Especially when a user has write access to that file it seems to
me also an security issue, when PHP allows to set/change critical settings
there.tl;dr: There is probably a reason, why your provider doesn't allow you to
change php.ini settings directly.Regards,
Sebastian
They run a LOT of different security setups for each SAPI. Each with it's
own chroot'd environment. And for us to be able to configure all the setups
with the same settings that we supply via our repo, it was set to use the
additional directory. But we have CLI (for crontab) and FastCGI setups.
All extensions are loaded via a separate ini file (seems a consistent
pattern I've seen before). But no mechanism to say xxx-cli.ini or
xxx-fastcgi.ini (for example) in the additional directory.
The patch allows ANY ini file to have [SAPI=xxxx] sections. This can act as
an alternative to having separate ini files for each SAPI when only one or
2 settings may be different.
Richard.
--
Richard Quadling
Just my 2 cents, but that sounds more like an issue with your
provider/hoster and not with PHP. I always thought of the additional
php.ini as a way to change some details and not a way to set up the whole
runtime. Especially when a user has write access to that file it seems to
me also an security issue, when PHP allows to set/change critical settings
there.
You totally miss the point, Sebastian. As Richard already explained in
his example, he as access to the ini-scan-dir, so he could set
whatever setting he wants, just not SAPI-specific, but for all SAPIs.
--
Regards,
Mike
2013/11/20 Michael Wallner mike@php.net
Just my 2 cents, but that sounds more like an issue with your
provider/hoster and not with PHP. I always thought of the additional
php.ini as a way to change some details and not a way to set up the whole
runtime. Especially when a user has write access to that file it seems to
me also an security issue, when PHP allows to set/change critical
settings
there.You totally miss the point, Sebastian. As Richard already explained in
his example, he as access to the ini-scan-dir, so he could set
whatever setting he wants, just not SAPI-specific, but for all SAPIs.
OK, but that doesn't change my opinion, that this in the hosters
responsibility, what he provides and what not.
--
Regards,
Mike
2013/11/20 Michael Wallner mike@php.net
Just my 2 cents, but that sounds more like an issue with your
provider/hoster and not with PHP. I always thought of the additional
php.ini as a way to change some details and not a way to set up the whole
runtime. Especially when a user has write access to that file it seems to
me also an security issue, when PHP allows to set/change critical
settings
there.You totally miss the point, Sebastian. As Richard already explained in
his example, he as access to the ini-scan-dir, so he could set
whatever setting he wants, just not SAPI-specific, but for all SAPIs.OK, but that doesn't change my opinion, that this in the hosters
responsibility, what he provides and what not.
INI sections allow one to customize directories settings and having
this feature to do some other settings based on the SAPI looks like a
good complement.
Obviously shared hosted applications are not the target for such
features as they usually do not have access to php.ini but .htacess or
.user.ini only.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
The patch allows [SAPI=xxx] sections and they operate in a very similar way
to the [HOST] and [PATH] sections.
That would be a good addition, but I wonder what would be the priority
of sections?
Because that's something which needs to be carefully documented
or is it just "latest wins"?
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
The patch allows [SAPI=xxx] sections and they operate in a very similar
way
to the [HOST] and [PATH] sections.That would be a good addition, but I wonder what would be the priority
of sections?Because that's something which needs to be carefully documented
or is it just "latest wins"?
SAPI is applied first, then the current order of HOST and then PATH. HOST
and PATH only apply to specific SAPIs it seems (CGI and FPM).
SAPI would apply to all SAPIs.
Richard.
--
Richard Quadling
Twitter : @RQuadling
Le 16/11/2013 12:54, Richard Quadling a écrit :
Hi.
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.
Seems usefull.
My use case is that the provider we are currently using does not allow us
to have our own INI file, just the additional directory, and there is no
way to differentiate between a CLI and a FAST-CGI setup in the additional
directory.
Another usecase, looking at pecl/sdl extension, it seems clear it should
be "cli" only (same case as RIP gtk2).
So, I'm +1 for this feature.
Remi.
The patch allows [SAPI=xxx] sections and they operate in a very similar way
to the [HOST] and [PATH] sections.Please can this be considered for inclusion into PHP at some stage.
Regards,
Richard Quadling.
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.
Mind that we have per-SAPI configuration files (php-$SAPI.ini).
I'd like to keep the the number of ways to configure PHP limited in
order to prevent a mess ...
johannes
Le 25/11/2013 17:10, Johannes Schlüter a écrit :
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.Mind that we have per-SAPI configuration files (php-$SAPI.ini).
I'd like to keep the the number of ways to configure PHP limited in
order to prevent a mess ...
For downstream distribution, for additionnal extensions we used to only
provide an additional file in php.d, as we cannot change main .ini.
Remi.
johannes
Le 25/11/2013 17:10, Johannes Schlüter a écrit :
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.Mind that we have per-SAPI configuration files (php-$SAPI.ini).
I'd like to keep the the number of ways to configure PHP limited in
order to prevent a mess ...For downstream distribution, for additionnal extensions we used to only
provide an additional file in php.d, as we cannot change main .ini.Remi.
johannes
--
What he said.
--
Richard Quadling
Twitter : @RQuadling
For downstream distribution, for additionnal extensions we used to only
provide an additional file in php.d, as we cannot change main .ini.
The implicit question was: Is there a smarter way to reform ini usage
instead of adding yet another thing to mind?
johannes
The implicit question was: Is there a smarter way to reform ini usage
instead of adding yet another thing to mind?
Is there a particular reason that configure-time
directive --with-config-file-scan-dir does exist,
but run-time directives "include" and/or "includedir" do not?
b.
I created a patch https://github.com/php/php-src/pull/466 to allow ini
files to have a SAPI section, just like they can have a HOST and PATH
section.Mind that we have per-SAPI configuration files (php-$SAPI.ini).
I'd like to keep the the number of ways to configure PHP limited in
order to prevent a mess ...
In a per sapi ini file, the use of [SAPI=] for a non matching SAPI would
have no effect (so at least it is safe to put them in).
And just to repeat, the use of the additional directory for INI files
precludes the use of sapi specific ini files, and this route is what I'm
using to allow me the flexibility I need with our current hoster.
Regards,
Richard.
--
Richard Quadling
Twitter : @RQuadling