PHP class files without <?php at the top

Am 07.04.2012 16:07, schrieb Derick Rethans:

and no the world is not turning around you or even around PHP

I will once more suggest you tune down your language on the
mailinglists. It's often rude and offensive. Let this be your last
warning

and what is there exactly rude?

this is simply the truth
or do you believe the world is turning around one person or PHP?

if someone brings proposals which are so less thight
what would you giev as answer? wait until enough people
not care enough abut the impacts start to implement
changes and then wait how to live with them?

i was there too often and nobody gives me back the wasted
lifetime for modify things after changes with zero benefit
and large impact - and what you lear after enough such
changes is that a "in my opinion not so a good idea" will
be ignored if someone loves to make changes

Am 07.04.2012 16:00, schrieb Tom Boutell:

That's a good point too.

I think this is a better proposal:

include_code, require_code, and require_code_once would work just like
include, require and require_once, except that the parser would start
out in PHP mode.

would you please leave this world in peace?

what do you think happens with hundret thousands of existing
include-files out there which are containing only HTML?

why do you simply not realize that you have way too few knowledge
and tchnical education to partly understand the side effects
small changes in a general behavior are having and that the
benefit has to be a REAL LARGE ONE for everybody to accept
the possible damage - which is not the case here

where are your proposals for bash and other unix shells
hwo they have to work if there is a whitespace before
#!/bin/sh? what have you got as answer there?

again: please leave the world in peace with your poorly
thought proposals - and yes this is a really polite answer
compared with the thoughts running through my mind
while reading your stuff

From: Tom Boutell [mailto:tom@punkave.com]

That's a good point too.

I think this is a better proposal:

include_code, require_code, and require_code_once would work just like include, require and require_once, except that the parser would start out in PHP mode.

I don't like this, but it's closer. I hate the idea of adding a whole mess of one-off functions just to support a single coding style feature that doesn't seem to have very much support. There are a variety of other ideas that have been floating around that request changes to how the parser handles specific code (different short tags, sandboxing, auto-escaping, etc.).

What if you have just ONE function with a variety of options? Something like:

execute_file('path/to/foo.php', array(
'require'=>true,
'once'=>true,
'begin_code'=>'<?php ',
'shorttags'=>array('<?=','?>'),
'autoescape'=>function($str){return htmlentities($str, ENT_QUOTES | ENT_HTML5, 'UTF-8');},
...
));

This would provide a single consistent hook for any further DSL like features without impacting the behavior of any existing code. Some other options that might make sense:

lint (like command line)
end_code (similar to command line, corresponds with begin_code (also command line))
args (also command line)
Any PHP_INI_ALL directives

John Crenshaw
Priacta, Inc.

That's a good point too.

I think this is a better proposal:

include_code, require_code, and require_code_once would work just like
include, require and require_once, except that the parser would start
out in PHP mode.

Those might be nice functions to have, but ...

.phpc is then just a convention for naming PHP files that start out
with code - a convention that autoloaders should respect, just as they
now respect the .php convention. "The user asked for the Monkey class,
and I see Monkey.phpc is out there; I'll grab that with
require_code_once."

… I think this isn't quite as simple as you make it out to be. Any autoloader that cared about bc would have to have code like

if(file_exists(.phpc)) require_code() else if(file_exists(.php)) require() else HCF()

There's a reason everyone settled around a single extension, and not the plethora we used to have (php, phtml, php3/php4, others?). Even in the rainbows-and-unicorns world where everyone always has an opcode cache and suitably tuned stat cache, that extra call to file_exists that will likely happen while waiting for files to be renamed and tested still isn't free. Also, I'm willing to bet that in the unlikely event you chose to drop out of PHP mode to dump a block of HTML, the awkwardness of a sudden ?> without a leading <?php would make the discussions about whether or not to have a trailing ?> at the end of files look like hyper-civilized discourse in comparison. (Though, it might be an interesting discussion regarding making the hypothetical require_code only (directly) include files that are pure code, with no <?php ?> tags allowed.)

Personally, I think the cognitive overhead the <?php ?> tags impose is pretty tiny. Yeah, you get weird errors sometimes, but once you understand what's going on, it's easy to fix (and generally easy to spot, if you're using version control). I really can't recall the last time it's happened to me and it took more than ten seconds to identify and fix. It's just one of the weird things about php. Every language has its rough edges, and in comparison, I really don't think this one even ranks in the top ten. There are plenty other parts of PHP that are far more awkward that could use addressing first (but won't, because of the bc break involved; haystack, meet needle).

You could also view <?php at the top of the file as a sort of magic number indicating the file type (such as used in many binary file formats: gifs always start with GIF87a/GIF89a, java class files with 0xCAFEBABE, etc). It's unlikely a file that starts with <?php is anything but.

-John

Putting this decision on the autoloader makes more sense because
autoloaders already contain assumptions about file extensions. They
have to in order to do their job of translating a class name to a
particular path somewhere.

Folks who did not care for this functionality could then choose to
entirely ignore it. Class library developers who liked it would make
autoloaders available that honored it, freeing end-user developers
from thinking about it. It becomes self-contained, and people who are
writing old-school .php standalone scripts or pages are entirely
unaffected.

From the viewpoint of someone writing reusable classes, the need to
start with <?php and reprimand anybody who accidentally puts a newline
above it is a silly annoyance they don't experience with other tools.

That said, you are making valid points, I'm not convinced myself that
"file extensions" necessarily should or could be determined in every
context. But it seems the most viable way of addressing the issue - if
a viable way even exists. Partly I want to convince myself that this
either can or can't ever be improved, and move on either way (:

That "silly annoyance" doesn't seem to bother anyone who writes command line tools, which require the #! line specifying the command interpreter to be the first bytes in the file, with no leading white space whatsoever. Especially on unix systems (but also on the Mac), the file extension does not affirmatively indicate the file type or whether or not it can be executed.

Also, from a CLI perspective, you don't want extensions in the names of your scripts, because then it causes problems/confusion/extra work if you later decide to change the language the script is written in.

-John

--
John Bafford
http://bafford.com/

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--

--
John Bafford
http://bafford.com/

That's a good point too.

I think this is a better proposal:

include_code, require_code, and require_code_once would work just like
include, require and require_once, except that the parser would start
out in PHP mode.

.phpc is then just a convention for naming PHP files that start out
with code - a convention that autoloaders should respect, just as they
now respect the .php convention. "The user asked for the Monkey class,
and I see Monkey.phpc is out there; I'll grab that with
require_code_once."

Putting this decision on the autoloader makes more sense because
autoloaders already contain assumptions about file extensions. They
have to in order to do their job of translating a class name to a
particular path somewhere.

Folks who did not care for this functionality could then choose to
entirely ignore it. Class library developers who liked it would make
autoloaders available that honored it, freeing end-user developers
from thinking about it. It becomes self-contained, and people who are
writing old-school .php standalone scripts or pages are entirely
unaffected.

Tony I think your idea has some merit. If it were up to me I'd remove
<?php all together. It really is bad practice to mix HTML into code.

But I feel that adding new keywords is not the way to do it.
Personally I'd like to see a php.ini setting to disallow the ending ?>
tag and assume .php files just have PHP code. The starting <?php tag
would be optional. White space would be ignored and non-white space
characters before <?php would throw a fatal error.

Doing it this way would disallow bad practices but still make existing
PHP scripts compatible.

I think that doing that would be quite reasonable. Those who complain
about it likely ignore industry best practices anyway. This option
could be turned off by default at first, made default later, and then
?> be deprecated all together.

So with this option enabled ?> is forbidden, <?php is optional, and
the text before <?php is handled differently - white spaces ignored,
text before throws an error (unless it's a shebang line in cli mode).

Hopefully that made sense. Does this sound good to you?

I'm sorry you had to endure such a nasty troll. I am so sick of self
righteous bullies who think they know it all.

Luke

From the viewpoint of someone writing reusable classes, the need to
start with <?php and reprimand anybody who accidentally puts a newline
above it is a silly annoyance they don't experience with other tools.

That said, you are making valid points, I'm not convinced myself that
"file extensions" necessarily should or could be determined in every
context. But it seems the most viable way of addressing the issue - if
a viable way even exists. Partly I want to convince myself that this
either can or can't ever be improved, and move on either way (:

That "silly annoyance" doesn't seem to bother anyone who writes command line tools, which require the #! line specifying the command interpreter to be the first bytes in the file, with no leading white space whatsoever. Especially on unix systems (but also on the Mac), the file extension does not affirmatively indicate the file type or whether or not it can be executed.

Also, from a CLI perspective, you don't want extensions in the names of your scripts, because then it causes problems/confusion/extra work if you later decide to change the language the script is written in.

-John

--
John Bafford
http://bafford.com/

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

That's a good point too.

I think this is a better proposal:

...

Tom, sorry! For some reason I thought Tony :). On my phone... Not as
intuitive as my desktop...

Luke

Hi,

2012/4/9 Arvids Godjuks arvids.godjuks@gmail.com:

8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki yohgaki@ohgaki.netнаписал:

2012/4/8 Ángel González keisial@gmail.com:

Hi,

The only valid reason for removing <?php from PHP script would be
security.

Since the null byte detection for fopen, remote/local script inclusion
became much harder than before. However, it's still possible and very
easy compare to other languages. Script execution is critical security
problem and it's worth to make it better.

If there is a switch that turns off PHP's template engine nature, PHP
could be more secure than now.

php.ini
template_mode = on   ; INI_ALL On by default

php -t foo.php   # template mode by default
php -T foo.php  # template mode off

People has option to make their code a little secure than now
or stick with current behavior.

Regards,
How does it help security?
If any, requiring '<?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.

Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.

For example, malicious PHP script may be in GIF something like

gif89a ...any data.. <?php exec('rm -rf /') ?>

and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.

Regards,

--
Yasuo Ohgaki

--

Improperly configured WEB server is not the reason to change the most basic
part of the language that will break every damn application out there.

This is not an configuration issue, but a security vulnerability that
can simply closed by disabling embed mode.

As I mentioned already, injecting malformed PHP scripts into files
is too easy compare to other languages. This could be improved
by simple modification and we can maintain compatibility with it.

I don't see anything wrong here.

Yet another PHP script injection example.
There are many applications that store user inputs in $_SESSION.
Attacker can inject PHP script into $_SESSION, then locally include
it. This is easy since attacker knew their session ID and path to
session file is can be guessed easily. All attacker has to do is
finding a vulnerable include()/require() to attack.

Regards,

--
Yasuo Ohgaki