Hi, 2012/4/10 Kris Craig <kris.cr...@gmail.com>: > > > On Mon, Apr 9, 2012 at 7:02 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> >> 2012/4/10 Kris Craig <kris.cr...@gmail.com>: >> > On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott <l...@cywh.com> wrote: >> > >> >> On 4/9/12 5:02 PM, "Kris Craig" <kris.cr...@gmail.com> wrote: >> >> >> >> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell <t...@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 yohg...@ohgaki.net > > --Kris > >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net >> >> >> > >> > --Kris >> > >> > >> >> Luke >> >> >> >> >> >> > >> >> >--Kris >> >> > >> >> > >> >> > >> >> >> >> >> >> On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott <l...@cywh.com> wrote: >> >> >> > On 4/9/12 3:53 PM, "Tom Boutell" <t...@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 <l...@cywh.com> wrote: >> >> >> >>> Tom, >> >> >> >>> >> >> >> >>> On 4/9/12 3:17 PM, "Tom Boutell" <t...@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.cr...@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 >> >> >> >> >> >> >> >> >> >> >> >> > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
