Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56292
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain mit.edu designates 18.7.68.37 as permitted sender)
Content-Type: text/plain; charset=UTF-8
Cc: internals <internals@lists.php.net>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
In-reply-to: <4EBD8967.8040606@lerdorf.com>
References: <1320740449-sup-5688@ezyang> <4EB8EAF1.3040104@lerdorf.com> <1320981061-sup-2803@ezyang> <4EBD79A5.2020604@lerdorf.com> <1321040435-sup-2225@ezyang> <4EBD8967.8040606@lerdorf.com>
Date: Fri, 11 Nov 2011 16:43:07 -0500
Message-ID: <1321047664-sup-8238@ezyang>
User-Agent: Sup/git
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Load extensions for .user.ini files
From: ezyang@MIT.EDU ("Edward Z. Yang")

Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011:
> Well, it is simple enough that we don't really need a patch. However,
> generally if you want to submit a patch it needs to be against a current
> svn branch and not an old release. You want to minimize the work people
> will need to do to look at your suggested change.

Gotcha.

> The other issue with your patch is that you are enabling this for the
> fpm sapi. I thought we agreed that this should only be in the sapis that
> supported dl() and those are cgi, cli and embed. And .user.ini doesn't
> apply to embed, so it would just be cli and cgi because these are the
> non-persistent cases where there is no danger of screwing up the next
> request with a bad extension in a .user.ini file.

Hmm, it looks like cli doesn't have .user.ini support at all.  Does this
mean we should implement .user.ini for these SAPIs? I'd be in favor.

Edward

> 
> -Rasmus
> 
> On 11/11/2011 11:42 AM, Edward Z. Yang wrote:
> > http://svn.php.net/repository/php/php-src/branches/PHP_5_3
> > r318957
> > 
> > We also applied it to 5.3.8 release, although we had to fix up the patch
> > for that.  I can port it to 5.4.
> > 
> > Edward
> > 
> > Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011:
> >> Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk
> >>
> >> It is short and simple so I could do it manually, of course, but I'd
> >> like to know what you have been testing it against.
> >>
> >> On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
> >>> Here is the proposed patch (sans tests; we did our own manual testing
> >>> on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
> >>> tests when you say so):
> >>>
> >>>     http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch
> >>>
> >>> The change to zlist_clean is necessary because otherwise extension_lists can't
> >>> be reused for the second round of extension appliations (since the head and
> >>> tail pointers have garbage in them).  You should probably take that fix regardless
> >>> of what you think of the feature change.
> >>>
> >>> Edward
> >>>
> >>> Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
> >>>> On 11/08/2011 12:23 AM, Edward Z. Yang wrote:
> >>>>> Hello all,
> >>>>>
> >>>>> My team is interested in permitting .user.ini files to load
> >>>>> extensions.  We believe this to be a simple fix: add
> >>>>> an invocation of php_ini_register_extensions to the end
> >>>>> of sapi/cgi/cgi-main.c.
> >>>>>
> >>>>> I don't believe this steps on any invariants, since extensions
> >>>>> can usually be loaded arbitrarily late.
> >>>>>
> >>>>> Let me know what the list thinks.  I can submit a patch and tests
> >>>>> if y'all decide it's a good idea.
> >>>>
> >>>> You are aware that these extensions can't be unloaded, right? So one
> >>>> user loading an extension will potentially be stepping on another user
> >>>> and breaking their code.
> >>>>
> >>>> -Rasmus