Re: RFC: source files without opening tag

Hi, 2012/4/10 Kris Craig <kris.craig@gmail.com>: > > > On Mon, Apr 9, 2012 at 7:02 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: >> >> 2012/4/10 Kris Craig <kris.craig@gmail.com>: >> > On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott <luke@cywh.com> wrote: >> > >> >> On 4/9/12 5:02 PM, "Kris Craig" <kris.craig@gmail.com> wrote: >> >> >> >> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell <tom@punkave.com> wrote: >> >> > >> >> >> Let me be very clear about that... I am NOT proposing that <?php at >> >> >> the top be mandatory in a file loaded in code mode! I don't want to >> >> >> type it ever again outside of a template file, personally. See the >> >> >> title of the RFC. >> >> >> >> >> > >> >> >But again, how then do you intend to make it so that a pure-code file >> >> > can >> >> >be called directly from the webserver on a host where the developer >> >> >doesn't >> >> >have access to most config options?  This is a very common scenario >> >> > that >> >> >cannot be ignored.  If not a <?phpp tag, then *something* in that file >> >> > has >> >> >to identify it as pure code otherwise this just isn't workable. >> >> > >> >> >Any INI option would be problematic because that would essentially >> >> > cause >> >> >all scripts relying on the setting you didn't choose to break.  And >> >> >unfortunately, recognizing a new file extension could pose problems >> >> > for >> >> >people running on heavily restricted hosts that currently have PHP >> >> > support >> >> >"built-in".  While I would never host on one of those services >> >> >myself, >> >> > I >> >> >don't like the idea of suddenly alienating everyone who does. >> >> > >> >> >I'd totally be open to an alternative to the <?phpp tag that can >> >> > withstand >> >> >scrutiny, but so far I haven't seen one.  And absent that, there's >> >> >no >> >> > way >> >> >I >> >> >could support this, which really sucks because at least conceptually I >> >> >think it's a really good idea. >> >> >> >> >> >> If the default is "template mode" and the "<?php" tag is >> >> optional (at >> >> the >> >> top) in "code" mode there shouldn't be any problems. >> >> >> >> We don't need to change or leave out the tag entirely. >> >> >> >> Is there a problem with people being able to choose "template mode" or >> >> "code mode" as the default in the php.ini file if "template >> >> mode" is >> >> the >> >> default if not specified? >> >> >> > >> > I think so, yes.  A config option that causes massive BC breakage >> > doesn't >> > become ok simply because it defaults to current behavior.  I just can't >> > envision any situation in which having that option switched on would not >> > cause problems, unless that server is *only* running scripts that assume >> > code mode.  However, what if you want to use two scripts, but one >> > assumes >> > code and the other assumes HTML?  The ini_set() function would be pretty >> > much useless given the circumstances. >> > >> > Instead, I would have an optional <?phpp tag at the top of the file. >> >  This >> > would be in addition to the file extension/SAPI approach and the require >> > keyword approach.  In other words, perhaps an "all of the above" >> > strategy >> > is what's neeeded here.  But either way, I just don't think an INI >> > setting >> > would be feasible. >> >> Hi, >> >> I guess you are trying to fix other problem than me, but >> please have a look this RFC >> >> https://wiki.php.net/rfc/nophptags >> >> INI setting is feasible for controlling template(embed) mode. It's easy to >> understand what it does also. >> PHP programmers may write >> >> ini_set('template_mode', 'off'); // in bootstrap. older PHP just >> ignores >> this. >>                                                  // Admin may put >> it >> in php.ini or .htaccess also. >> >> then they would set template_mode="on"/"off" just before/afeter render >> templates. >> >> ini_set('template_mode', on); // old PHP ignores >> render_template($my_tpl, $my_tpl_vars); // do whatever is needed as >> template engine >> ini_set('template_mode', off); // old PHP ignores >> >> Above code works for both template_mode="on" and "off" in php.ini. >> >> In real world, programmer would write ini_set() inside of >> render_template(). >> This simple change makes PHP free from fatal LFI mess while maintaining >> compatibility with older PHP. >> >> If you don't want to write needless PHP tags, you don't have to with this >> RFC, too. > > > Yeah I get that.  I'm just not sure I see the point.  Aren't there already > text editors that handle the <?php tag for you?  I'm just really nervous > about creating an INI setting that would bork everything if there's a > conflict between parallel running libraries and doesn't really provide any > benefit other than an extremely minor convenience for some.  It's a slight > convenience, but at the cost of creating a single INI setting that radically > alters the way PHP scripts are executed.  What you're looking to do does > have some merit, but it just doesn't pass the cost/benefit test for me. I just would like to make PHP as safe as other languages (Ruby/Perl/Python/etc) FLI problem is unique to PHP due to a embedded nature of PHP. The php.ini setting do not affect much. If person who don't know what is does set to template_mode=off, PHP just raises syntax errors for script expects embedded mode. > Btw I did see that RFC, but I was under the impression that it was just an > April Fool's prank.  ;P Yes, Morihoshi was made it for April Fool for a joke, but he was half serious. And I'm really serious about this to make PHP safer :-) Mandatory embedded mode is the last PHP weak point with respect to other major scripting languages. IMHO. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net > > --Kris > >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohgaki@ohgaki.net >> >> >> > >> > --Kris >> > >> > >> >> Luke >> >> >> >> >> >> > >> >> >--Kris >> >> > >> >> > >> >> > >> >> >> >> >> >> On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott <luke@cywh.com> wrote: >> >> >> > On 4/9/12 3:53 PM, "Tom Boutell" <tom@punkave.com> >> >> >> > wrote: >> >> >> > >> >> >> >>I see why you want to allow <?php at the top to be optional in >> >> >> >> 'code >> >> >> >>mode,' rather than disallowed in code mode. But your purpose >> >> >> >>is to >> >> >> >>allow legacy code to be autoloaded without knowing in advance >> >> >> >> whether >> >> >> >>it starts with <?php or not. >> >> >> >> >> >> >> >>But that would probably lead in practice to the use of a single >> >> >> >> file >> >> >> >>extension for old and new class files. >> >> >> >> >> >> >> >>And that, in turn, would lead to source code being spewed to the >> >> >> >>browser for all to see if a perfectly respectable autoloader >> >> >> >>circa >> >> >> >> PHP >> >> >> >>5.3 runs into one of these new files. >> >> >> >> >> >> >> >>This is a much more significant security issue than some of those >> >> >> >>mentioned previously because perfectly well-written code would >> >> >> >> display >> >> >> >>this behavior if someone unknowingly drops a newer library into, >> >> >> >> say, >> >> >> >>the lib/ folder of a Symfony 1.4 project. Ouch. >> >> >> > >> >> >> > >> >> >> > So are you saying the starting "<?php" tag should be >> >> >> > required in >> >> >> > "code >> >> >> > mode"? >> >> >> > >> >> >> > If so, I'm ok with that as long as: >> >> >> > >> >> >> > - "?>" is forbidden >> >> >> > >> >> >> > - Text before the opening <?php tag (literal text or >> >> >> > white-spaces) >> >> >> > is >> >> >> > either ignored or throws an error instead of printing to the >> >> >> > output >> >> >> buffer. >> >> >> > >> >> >> > If that's not what you mean, please clarify. >> >> >> > >> >> >> > Luke >> >> >> > >> >> >> >> >> >> >> >>It would be much better for that autoloader to just ignore the >> >> >> >> file >> >> >> >>because it has a new extension. This way the problem is >> >> >> >> immediately >> >> >> >>apparent: >> >> >> >> >> >> >> >>"Hey, my class didn't load, something must be up. Oh my >> >> >> >>PHP is old >> >> >> >>and/or this autoloader doesn't know about .phpc files, what >> >> >> >>are >> >> >> >> they >> >> >> >>anyway... google google... aha, I need PHP 5.x and an updated >> >> >> >>autoloader. Grumble. Okay." >> >> >> >> >> >> >> >>This is a much safer outcome. >> >> >> >> >> >> >> >>On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott <luke@cywh.com> >> >> >> >>wrote: >> >> >> >>> Tom, >> >> >> >>> >> >> >> >>> On 4/9/12 3:17 PM, "Tom Boutell" >> >> >> >>> <tom@punkave.com> wrote: >> >> >> >>> >> >> >> >>>>My original goal was to stop typing <?php in pure code >> >> >> >>>>files. >> >> >> >>>> That >> >> >> >>>>includes at the top. I think it's entirely >> >> >> >>>>reasonable to achieve >> >> >> >>>> it >> >> >> >>>>with an option to the require keywords for this purpose >> >> >> >>>>and a >> >> >> >>>> naming >> >> >> >>>>convention to be followed by autoloaders. Keep in mind >> >> >> >>>>how >> >> >> >>>> rarely >> >> >>you >> >> >> >>>>have to change them. We're talking about code >> >> >> >>>>maintained by a >> >> >> >>>>relatively small number of very sharp developers. They >> >> >> >>>>can >> >> >> >>>> handle a >> >> >> >>>>few flags (: >> >> >> >>>> >> >> >> >>>>The prohibition of ?> still seems unnecessary and >> >> >> >>>>perhaps >> >> >> >>>> divisive, >> >> >> >>>>but if it were preferable to the majority to prohibit >> >> >> >>>>?> in a >> >> >> >>>> pure >> >> >> >>>>code file, I could live with that as long as classic PHP >> >> >> >>>>files >> >> >> >>>> are >> >> >> >>>>also 100% supported and remain the default. I'm >> >> >> >>>>trying to craft >> >> >> >>>> a >> >> >> >>>>broadly acceptable compromise that still achieves the >> >> >> >>>>original >> >> >> >>>> goal >> >> >>of >> >> >> >>>>allowing people to write "just code" in a class >> >> >> >>>>file. >> >> >> >>> >> >> >> >>> >> >> >> >>> I think you can you achieve that by making "template >> >> >> >>> mode" >> >> >> >>> default >> >> >>and >> >> >> >>>the >> >> >> >>> default changeable in the php.ini file. >> >> >> >>> >> >> >> >>> Something like this: >> >> >> >>> >> >> >> >>> /* >> >> >> >>>    Code only, <?php at top optional, no ?>. >> >> >> >>>    Text before opening <?php silently dropped >> >> >> >>> >> >> >> >>> */ >> >> >> >>> >> >> >> >>> require "/path/to/somefile.php", INCLUDE_CODE; >> >> >> >>> >> >> >> >>> /* >> >> >> >>>    Works exactly as it is now: <?php and ?> allowed. >> >> >> >>>    Text betweeen ?>...<?php printed to output >> >> >> >>> buffer. >> >> >> >>> */ >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> require "/path/to/anotherfile.php", >> >> >> >>> INCLUDE_TEMPLATE; // As it >> >> >> >>> is >> >> >>now >> >> >> >>> >> >> >> >>> /* >> >> >> >>>    By default INCLUDE_TEMPLATE >> >> >> >>>    Can change default mode in php.ini to be INCLUDE_CODE >> >> >> >>> if >> >> >> >>> desired. >> >> >> >>> */ >> >> >> >>> >> >> >> >>> require "/path/to/anotherfile.php"; // As it is >> >> >> >>> now >> >> >> >>> >> >> >> >>> >> >> >> >>> Personally I would like to be able to do something like this >> >> >> >>> in >> >> >> >>> my >> >> >>auto >> >> >> >>> loader: >> >> >> >>> >> >> >> >>> include $file, INCLUDE_CODE & INCLUDE_SILENT; >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> That way I can ensure pure code is being inserted and no >> >> >> >>> warnings >> >> >>are >> >> >> >>> thrown if the file doesn't exist (class undefined will >> >> >> >>> be thrown >> >> >> >>>anyway). >> >> >> >>> >> >> >> >>> I think it's important to make <?php optional at the >> >> >> >>> top if >> >> >> >>> you're >> >> >> using >> >> >> >>> existing or third party libraries that you can't >> >> >> >>> modify. At >> >> >> >>> least >> >> >>then >> >> >> >>> you'll be able to maintain backwards compatibility with >> >> >> >>> most >> >> >> >>> code >> >> >> >>>written >> >> >> >>> since PHP 5. >> >> >> >>> >> >> >> >>> (We don't need PHP_*. See the output of >> >> >> >>> get_defined_constants() >> >> >> >>> ). >> >> >> >>> >> >> >> >>> I like where this is going! Hopefully after the RFC has been >> >> >>finalized >> >> >> >>> everyone else will agree. >> >> >> >>> >> >> >> >>> >> >> >> >>>> >> >> >> >>>>On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig >> >> >> >>>> <kris.craig@gmail.com> >> >> >> wrote: >> >> >> >>> >> >> >> >>> >> >> >> >>> Kris, >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> Bah, right!  That damned <?xml tag.... >> >> >> >>>>> >> >> >> >>>>> I already know what everyone's reaction will >> >> >> >>>>> be, and it is >> >> >>probably a >> >> >> >>>>>REALLY >> >> >> >>>>> bad idea, but I feel obligated to at least mention >> >> >> >>>>> it:  Should >> >> >> >>>>> we >> >> >> >>>>>consider >> >> >> >>>>> replacing "<?..." with something that >> >> >> >>>>> doesn't conflict with >> >> >>anything, >> >> >> >>>>> perhaps starting in PHP 6?  No need to get out the >> >> >> >>>>> torches and >> >> >> >>>>>pitchforks, >> >> >> >>>>> everyone!  As insane and problematic as that would >> >> >> >>>>> be (i.e.. BC >> >> >>break >> >> >> >>>>>with >> >> >> >>>>> roughly 1/3 of the internet lol), I felt as though >> >> >> >>>>> the subject >> >> >>should >> >> >> >>>>>at >> >> >> >>>>> least be broached.  ;P >> >> >> >>> >> >> >> >>> >> >> >> >>> No need. Just keep it as <?php. It's already been >> >> >> >>> well >> >> >> >>> established. >> >> >>We >> >> >> >>> should ovoid overcomplicating it. >> >> >> >>> >> >> >> >>> Luke >> >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>-- >> >> >> >>Tom Boutell >> >> >> >>P'unk Avenue >> >> >> >>215 755 1330 >> >> >> >>punkave.com >> >> >> >>window.punkave.com >> >> >> >> >> >> >> >>-- >> >> >> >>PHP Internals - PHP Runtime Development Mailing List >> >> >> >>To unsubscribe, visit: >> >> >> >>http://www.php.net/unsub.php >> >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Tom Boutell >> >> >> P'unk Avenue >> >> >> 215 755 1330 >> >> >> punkave.com >> >> >> window.punkave.com >> >> >> >> >> >> -- >> >> >> PHP Internals - PHP Runtime Development Mailing List >> >> >> To unsubscribe, visit: >> >> >> http://www.php.net/unsub.php >> >> >> >> >> >> >> >> >> >> >> >> > >