Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59812
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXa554p45tbNFvtHQJiYTXaa0eD6r+qnExDVk+6e8PRvMw@mail.gmail.com>
References: <CAKOpQSwYe+tZ3JfLFWaOHCnBpUyy9yoA61=qLzbnnOKTL0mQdQ@mail.gmail.com>
	<CAGa2bXa554p45tbNFvtHQJiYTXaa0eD6r+qnExDVk+6e8PRvMw@mail.gmail.com>
Date: Thu, 12 Apr 2012 16:57:13 -0700
Message-ID: <CAKOpQSz1dcNpjp7aRzTQQ3Ot6TeFX9qvoeZBL2mOxhfp6RfjFA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442811e698aff04bd841d61
Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
From: kris.craig@gmail.com (Kris Craig)

--f46d0442811e698aff04bd841d61
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 12, 2012 at 4:38 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi,
>
> 2012/4/13 Kris Craig <kris.craig@gmail.com>:
> > Per recent discussions, I have drafted an RFC for this.  This proposal
> > offers what I believe to be a more sane and realistic approach to
> > addressing the question of incorporating a new breed of tag-less PHP
> > scripts.
> >
> > https://wiki.php.net/rfc/phpp
>
> This may work for LFI issue for new codes.
> Few questions.
>
> CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or else)
> It's like DOS, though.
>
> How do you enforce .phpp as script only for Web?
> Is it a rule for configuration? or .phpp just never supposed to locate
> under docroot?
> It relates previous question. How about bootstrap script for frameworks?
>

I'm not sure what the best SAPI configuration would be, but if I had to
throw out an educated guess, I'd say the .phpp extension would just go
through a separate handler.  All the code in the file would then be parsed
as PHP, with the added error conditions as described in the RFC.  So I
don't anticipate there being any problems once the webserver has been
configured to recognize the new file extension.  The files can be included
or accessed directly via HTTP (though in most cases I wouldn't recommend
that from an architectural standpoint, AJAX notwithstanding of course).


>
> > A regular .php script cannot be included from a .phpp script. An
> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
> thrown for require; in both instances, the included file will be ignored.
>
> Some people may try to make .phpp handled by web.
>

Though not necessarily required, my thinking is that that should be ok, so
long as the webserver is configured to know what to do with it of course.
It's conceivable that certain AJAX calls might want to take advantage of
pure scripts, for example.


> I cannot tell if this setting is going to be popular, but if it
> does, isn't it the end of embedded PHP?
>

I see no reason why it should be.  Embedded PHP will still be there exactly
as it is now; the .php file extension will not be changed by this RFC
whatsoever.  As far as whether people will continue using embedded PHP, I
have no idea and I'm guessing there'd probably strong opinions on both
sides of that.  This RFC doesn't attempt to address that question, though.
The future of embedded PHP is a separate topic entirely.  But my gut
feeling is, so long as there are developers who continue to want it, it'll
still be there for them.

It might be good if PHP is more tolerant for this usage.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--f46d0442811e698aff04bd841d61--