On Thu, Apr 12, 2012 at 4:38 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi, > > 2012/4/13 Kris Craig <kris.cr...@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 > yohg...@ohgaki.net >
