subject:"\[PHP\-DEV\] short_open


Edward Z. Yang wrote:

Rasmus Lerdorf wrote:

Sure, although if you are going to store the raw, I think it is
pointless to store the escaped version.


Yeah, I was thinking more of escaping data that is computationally
expensive; such as bbcodes or wikitext => HTML.


I am not advocating storing it either way, I am simply saying that by
default you should never work with raw user data. [snip] If you forget to fetch 
the raw
or if you forget to re-filter it through the appropriate filter for
whatever backend, then chances are your application won't work, or the
user will see strange output, but at least you will be failing safe,
instead of failing insecure.


I understand that and how your methodology works, but I've always
thought there was something fishy about it. I suppose this is the
reason: the default won't always be secure, because HTML (and other
formats too, I suppose) require a great variety of types of escaping.
Say we're placing data in a href="" attribute; the default HTML escaping
will protect against breaking out of the quote, but the user can still
pass javascript:xss() and cause problems.

There are two levels of escaping/validation that need to happen here:
the HTML escaping, and a URI validation. The default can lull users into
a false sense of security, especially for more subtle vectors, whereas
if you force people to be explicit you've at least *attempted* to make
them think about what output format they should be using. Either that,
or make it so that the only way for a developer to output something like
that is a manner that also supplies the context (for example, using a
DOM builder).

Of course, careless developers will still make careless mistakes, and I
agree that a sensible default will fix the majority of these issues.
Just not 100%.


Nothing will ever be 100%.  There will always be context issues, but no 
mechanism will fix those.




is another example of a no-win context.  There is simply no 
filter/untainter or whatever that will make this safe.  The best you can 
do is provide sensible default actions and make sure people realize that 
it isn't the entire solution.  But I don't think throwing our hands in 
the air and doing nothing to help the developers is the answer just 
because there are such contexts that can't be solved by filters.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-23 Thread Edward Z. Yang

Rasmus Lerdorf wrote:
> Sure, although if you are going to store the raw, I think it is
> pointless to store the escaped version.

Yeah, I was thinking more of escaping data that is computationally
expensive; such as bbcodes or wikitext => HTML.

> I am not advocating storing it either way, I am simply saying that by
> default you should never work with raw user data. [snip] If you forget to 
> fetch the raw
> or if you forget to re-filter it through the appropriate filter for
> whatever backend, then chances are your application won't work, or the
> user will see strange output, but at least you will be failing safe,
> instead of failing insecure.

I understand that and how your methodology works, but I've always
thought there was something fishy about it. I suppose this is the
reason: the default won't always be secure, because HTML (and other
formats too, I suppose) require a great variety of types of escaping.
Say we're placing data in a href="" attribute; the default HTML escaping
will protect against breaking out of the quote, but the user can still
pass javascript:xss() and cause problems.

There are two levels of escaping/validation that need to happen here:
the HTML escaping, and a URI validation. The default can lull users into
a false sense of security, especially for more subtle vectors, whereas
if you force people to be explicit you've at least *attempted* to make
them think about what output format they should be using. Either that,
or make it so that the only way for a developer to output something like
that is a manner that also supplies the context (for example, using a
DOM builder).

Of course, careless developers will still make careless mistakes, and I
agree that a sensible default will fix the majority of these issues.
Just not 100%.

-- 
 Edward Z. YangGnuPG: 0x869C48DA
 HTML Purifier  Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Stefan Walk wrote:

Rasmus Lerdorf schrieb:
Well, I actually have years of experience taking apps and making them 
run under my strict default filter.  And it tends to not be very many 
changes, if any at all.  In the O'Reilly case it gets changed to 
O'Reilly which for a pure web app is fine.  If all input 
consistently gets changed the same way then you can store O'Reilly 
in the backend and a search will still find it since the search query 
itself will be encoded the same way.  If you have non web tools 
working with the same backend data, then you may have a requirement to 
store it raw, in which case you'd need to poke a hole in your data 
firewall.


I have a hard time remembering the last at least half-serious web app 
that i touched that didn't at least include email functionality ... and 
even if it doesn't, storing scrambled data in the backend is not really 
a good idea, for example because it makes adding functionality - like 
email - that needs another encoding hard.


Like I said, I'm not advocating storing it encrypted, I was simply 
saying it isn't necessarily going to break anything running an app 
unchanged under a default filter.  And even if it does, in an app that 
does email, the breakage will be limited to some funny-looking ''s 
here and there in the emails that go out, assuming of course they aren't 
HTML emails, in which case it would look fine.  Failing safe like that 
is much better than having XSS issues everywhere.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Rasmus Lerdorf schrieb:
Well, I actually have years of experience taking apps and making them 
run under my strict default filter.  And it tends to not be very many 
changes, if any at all.  In the O'Reilly case it gets changed to 
O'Reilly which for a pure web app is fine.  If all input 
consistently gets changed the same way then you can store O'Reilly 
in the backend and a search will still find it since the search query 
itself will be encoded the same way.  If you have non web tools working 
with the same backend data, then you may have a requirement to store it 
raw, in which case you'd need to poke a hole in your data firewall.


I have a hard time remembering the last at least half-serious web app 
that i touched that didn't at least include email functionality ... and 
even if it doesn't, storing scrambled data in the backend is not really 
a good idea, for example because it makes adding functionality - like 
email - that needs another encoding hard.


Regards,
Stefan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Edward Z. Yang wrote:

Rasmus Lerdorf wrote:

Well, I actually have years of experience taking apps and making them
run under my strict default filter.  And it tends to not be very many
changes, if any at all.  In the O'Reilly case it gets changed to
O'Reilly which for a pure web app is fine.  If all input
consistently gets changed the same way then you can store O'Reilly
in the backend and a search will still find it since the search query
itself will be encoded the same way.  If you have non web tools working
with the same backend data, then you may have a requirement to store it
raw, in which case you'd need to poke a hole in your data firewall.


Rasmus, I'm sure these techniques work very well in practice. However,
it's important to note that it's still an optimization, a step down from
an "ideal" standard which would involve keeping raw data in the
database. In theory, the data in its purest form, with no extraneous
escaping, would be stored. In practice, most data will be used in a web
context and thus, as you note, escaping it as ' is perfectly acceptable.

I've always advocated storing both the pure data and the escaped version
(in a kind of cache) in the database, because if you store just the
escaped version you don't have any easy way (besides decoding) to get
the raw version back. Of course, this doubles the storage requirement.


Sure, although if you are going to store the raw, I think it is 
pointless to store the escaped version.  But this is not the point.  I 
am not advocating storing it either way, I am simply saying that by 
default you should never work with raw user data.  You should limit the 
scope in your code where raw data is used.  So if you need to store the 
raw data, fetch it just before storing it or just before sending a query 
to the backend.  Everywhere else that same piece of data is a very 
strictly escaped piece of information.  If you forget to fetch the raw 
or if you forget to re-filter it through the appropriate filter for 
whatever backend, then chances are your application won't work, or the 
user will see strange output, but at least you will be failing safe, 
instead of failing insecure.


There are so many places where one missed filter has been the downfall 
of a web app.  Think of an age or state select dropdown.  It's very easy 
to forget to filter such an innocent-looking field in a web app, and 
even a very strict default filter isn't likely to mess up a 2-letter 
state name or a 2-digit number so running such an app with a couple of 
missing filters isn't going to affect it at all.  It will simply make 
something that wasn't safe before, safe.


By the way, if anybody on the list has a web app they'd like me to 
check, you have probably heard of the tool I wrote for this purpose 
called Scanmus.  If you send me a note privately, I'd be happy to scan 
it for you, if for nothing else, to illustrate just how many web apps 
written by otherwise competent developers are insecure.


-Rasmus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-23 Thread Edward Z. Yang

Rasmus Lerdorf wrote:
> Well, I actually have years of experience taking apps and making them
> run under my strict default filter.  And it tends to not be very many
> changes, if any at all.  In the O'Reilly case it gets changed to
> O'Reilly which for a pure web app is fine.  If all input
> consistently gets changed the same way then you can store O'Reilly
> in the backend and a search will still find it since the search query
> itself will be encoded the same way.  If you have non web tools working
> with the same backend data, then you may have a requirement to store it
> raw, in which case you'd need to poke a hole in your data firewall.

Rasmus, I'm sure these techniques work very well in practice. However,
it's important to note that it's still an optimization, a step down from
an "ideal" standard which would involve keeping raw data in the
database. In theory, the data in its purest form, with no extraneous
escaping, would be stored. In practice, most data will be used in a web
context and thus, as you note, escaping it as ' is perfectly acceptable.

I've always advocated storing both the pure data and the escaped version
(in a kind of cache) in the database, because if you store just the
escaped version you don't have any easy way (besides decoding) to get
the raw version back. Of course, this doubles the storage requirement.

-- 
 Edward Z. YangGnuPG: 0x869C48DA
 HTML Purifier  Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Stefan Walk wrote:

Rasmus Lerdorf schrieb:
The alternative of relying on the developer remembering to filter 
simply doesn't work.  Wietse's taint mode is another approach, but it 
has performance implications.


As I said, when the backend does the escaping, you don't have to 
remember it.


filtering would fix, or they stem from people applying the wrong 
filters in the wrong situations which again would happen under any 
system.  What 


If the backend picked the escaping mechanism, *that* wouldn't happen (if 
the backend isn't buggy, but that can happen for any way)


The other thing this gives us is the ability to run 3rd-party 
untrusted apps.  You only need to find the 2 or 3 places where the app 
needs something other than the default filtered data and even the most 
insecure app can be run with some semblance of security.


"Some" is the right word here. That insecure app could leak information 
from your server, write or read data to/from locations it shouldn't, 
etc. Also, I don't think it would be just 2 or 3 places. It'll be more 
like every point where it's real user input (and not form ids, hidden 
values etc), because then you have to expect almost any char that your 
filter has to strip to be safe - Mr. O'Reilly won't be amused if he's 
called OReilly, O''Reilly, O'Reilly or O\'Reilly.


Well, I actually have years of experience taking apps and making them 
run under my strict default filter.  And it tends to not be very many 
changes, if any at all.  In the O'Reilly case it gets changed to 
O'Reilly which for a pure web app is fine.  If all input 
consistently gets changed the same way then you can store O'Reilly 
in the backend and a search will still find it since the search query 
itself will be encoded the same way.  If you have non web tools working 
with the same backend data, then you may have a requirement to store it 
raw, in which case you'd need to poke a hole in your data firewall.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Rasmus Lerdorf schrieb:
The alternative of relying on the developer remembering to filter simply 
doesn't work.  Wietse's taint mode is another approach, but it has 
performance implications.


As I said, when the backend does the escaping, you don't have to 
remember it.


filtering would fix, or they stem from people applying the wrong filters 
in the wrong situations which again would happen under any system.  What 


If the backend picked the escaping mechanism, *that* wouldn't happen (if 
the backend isn't buggy, but that can happen for any way)


The other thing this gives us is the ability to run 3rd-party untrusted 
apps.  You only need to find the 2 or 3 places where the app needs 
something other than the default filtered data and even the most 
insecure app can be run with some semblance of security.


"Some" is the right word here. That insecure app could leak information 
from your server, write or read data to/from locations it shouldn't, 
etc. Also, I don't think it would be just 2 or 3 places. It'll be more 
like every point where it's real user input (and not form ids, hidden 
values etc), because then you have to expect almost any char that your 
filter has to strip to be safe - Mr. O'Reilly won't be amused if he's 
called OReilly, O''Reilly, O'Reilly or O\'Reilly.


Regards,
Stefan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Stefan Walk wrote:

Rasmus Lerdorf schrieb:
It is, but it is magic_quotes done right.  You apply a really strict 
filter that makes your data safe for display and your backend by 
default.  The only place you can reliably do this this is at the point 
the data enters your system.  Once it is in, having to remember to 
apply a filter before you use the data will never work.  You might 
remember to do it 99.99% of the time, but that doesn't help you and 
you might as well not do it at all.  A bit like a condom with just one 
little hole.


-Rasmus


No, it's not "done right". To work for all cases, your "default filter" 
would basically have to return an empty string all the time (if you say 
"nonsense", does the default filter strip "From" from the start of a 
line so you can put it into an mbox?). And you don't need do do that to 
be safe, because you don't have to remember to apply a filter, you use 
the subsystem that needs the escaped data to escape the data itself. So, 
when passing an arg to a MySQL query, it gets escaped the right way (by 
using pepared statements, formatted query strings ... hundreds of 
possibilities). If you pass data to the "HTML output subsection", it 
gets escaped for use in HTML. Cause this is done implicitely, you never 
ever call an escaping function yourself, so there is no way to forget it.


But you know which backends you use.  I am not suggesting that PHP can 
supply a default filter that works for everyone.  But I am suggesting 
that you can supply a default filter that works for the backends you 
use.  The vast majority of people need data to be safe from HTML and 
MySQL/PostgreSQL.  So having a default filter that makes data safe for 
these uses and throw in Shell, CSS and Javascript as well, and you have 
a really powerful default filter.  Yes, there will always be other 
subsystems out there that needs other filtering, in which case you 
extend your default filter to cover those, or you wall off those 
subsystems and have a secondary filter layer.


The alternative of relying on the developer remembering to filter simply 
doesn't work.  Wietse's taint mode is another approach, but it has 
performance implications.


The data firewall approach is what I put in place at Yahoo 5+ years ago 
now.  We have hundreds of applications written by thousands of 
developers and it works.  Yes, there are still security issues from time 
to time, but they end up being logical flow issues that no amount of 
filtering would fix, or they stem from people applying the wrong filters 
in the wrong situations which again would happen under any system.  What 
we don't see are security problems caused by developers forgetting to 
filter a specific bit of user data.


The other thing this gives us is the ability to run 3rd-party untrusted 
apps.  You only need to find the 2 or 3 places where the app needs 
something other than the default filtered data and even the most 
insecure app can be run with some semblance of security.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Jared Williams schrieb:

A lot of people don't use templates, just raw PHP. So having a short tag
escaping would decrease XSS vulnerabilities.


Well, i don't think that would be wise, because then you'd have to watch 
if you're inside 


I don't understand why need to essentially duplicate all the variables just
to provide proper escaping. 


It's not "all" (usually the template uses far fewer vars than your 
controlling logic), and it's not "just" (you don't want foreach ($a as 
$b) in your template changing $b in your controlling logic), doing the 
include $template in a function call, after setting up the vars, 
protects you from side-effects of your templates.


Regards,
Stefan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Wietse Venema wrote:

Rasmus Lerdorf:

Soenke Ruempler wrote:

Hi Rasmus,

On 03/23/2008 03:32 PM, Rasmus Lerdorf wrote:

This is what the filter extension is for.  You should be working with 
escaped data by default and only poke a hole in your data firewall in 
the few places where you need to work with the raw data.  Doing it the 
other way around is going to lead to all sorts of security issues.
Mhm. Isn't the the right paradigm to prepare variables at the time they 
are passed into subsystems (sql, shell, html etc.)? So what do you mean 
with "escaped data" here? html/xml escaped, sql escaped (which sql 
system and which encoding?). Sounds a bit like magic_quotes reloaded 
*hides*
It is, but it is magic_quotes done right.  You apply a really strict 
filter that makes your data safe for display and your backend by 
default.  The only place you can reliably do this this is at the point 
the data enters your system.


Input fitering has valid uses, but protecting html/sql/shell/etc.
is not among them.  Legitimate input like O'Reilly requires different
treatments depending on html/sql/shell/etc. context. It would be
incorrect to always insert a \, it would be incorrect to always
remove the ', and it would be incorrect to always reject the input.


You can also choose to never store the raw single quote and always work 
with encoded data.  Or, as I suggest, always filter it by default and in 
the places where you want the raw quote back or you want it filtered for 
a specific use, specify explicitly which filter you want to apply.  It 
is the data firewall approach.  Filter everything by default with an 
extremely strict filter and poke holes in your data firewall as 
necessary.  It also makes it easy to audit your code because you only 
have to track look at the places where you have poked a hole.



Data flow control (a.k.a. taint support) can detect when output
isn't converted with the proper conversion function. This can be
done in reporting mode (my approach) or it can be done in "automatic
fixing" mode (other people).  These different approaches make
different trade-offs between programmer effort and system overhead,
and avoid the data corruption that input filtering would introduce.


Having to do active checks on each use is extremely expensive.  You said 
yourself you suggest only enabling this during development.  The data 
firewall approach isn't actually all that different from the taint 
approach.  The big win is that there is no runtime checking necessary 
and thus no performance hit.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Soenke Ruempler wrote:

Hi Rasmus,

On 03/23/2008 04:14 PM, Rasmus Lerdorf wrote:

It is, but it is magic_quotes done right.  You apply a really strict 
filter that makes your data safe for display and your backend by 
default.  The only place you can reliably do this this is at the point 
the data enters your system.  Once it is in, having to remember to 
apply a filter before you use the data will never work.  You might 
remember to do it 99.99% of the time, but that doesn't help you and 
you might as well not do it at all.  A bit like a condom with just one 
little hole.


Well, my point is: at the stage where user generated data enter your 
program you don't know for which subsystem to prepare it. Maybe for one, 
maybe for more of them (it's a common case that user input is first 
written to SQL backend and then displayed again).


So if everything is html escaped with the filter extension and I wanna 
put it into SQL I have to remember "ah all my input is escaped for html 
so I have to DECODE it and then prepare it to go into SQL". Now the 
question is: What's easier, more intuitive and less headaching?


No, that's the point.  You never ever decode data.  If you are using any 
sort of decode function, chances are your application is insecure.  The 
filter extension keeps a copy of the raw data internally.  The default 
filter you apply will filter for all the backends you use. 
htmlspecialchars with all single and double quotes converted as well, 
takes care of most commonly used stuff.  When you need the raw data, or 
the data filtered in a different way, you ask the filter extension to 
re-filter from the stored raw data, you don't decode.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-23 Thread Wietse Venema

Rasmus Lerdorf:
> Soenke Ruempler wrote:
> > Hi Rasmus,
> > 
> > On 03/23/2008 03:32 PM, Rasmus Lerdorf wrote:
> > 
> >> This is what the filter extension is for.  You should be working with 
> >> escaped data by default and only poke a hole in your data firewall in 
> >> the few places where you need to work with the raw data.  Doing it the 
> >> other way around is going to lead to all sorts of security issues.
> > 
> > Mhm. Isn't the the right paradigm to prepare variables at the time they 
> > are passed into subsystems (sql, shell, html etc.)? So what do you mean 
> > with "escaped data" here? html/xml escaped, sql escaped (which sql 
> > system and which encoding?). Sounds a bit like magic_quotes reloaded 
> > *hides*
> 
> It is, but it is magic_quotes done right.  You apply a really strict 
> filter that makes your data safe for display and your backend by 
> default.  The only place you can reliably do this this is at the point 
> the data enters your system.

Input fitering has valid uses, but protecting html/sql/shell/etc.
is not among them.  Legitimate input like O'Reilly requires different
treatments depending on html/sql/shell/etc. context. It would be
incorrect to always insert a \, it would be incorrect to always
remove the ', and it would be incorrect to always reject the input.

>  Once it is in, having to remember to apply 
> a filter before you use the data will never work.  You might remember to 
> do it 99.99% of the time, but that doesn't help you and you might as 
> well not do it at all.  A bit like a condom with just one little hole.

Data flow control (a.k.a. taint support) can detect when output
isn't converted with the proper conversion function. This can be
done in reporting mode (my approach) or it can be done in "automatic
fixing" mode (other people).  These different approaches make
different trade-offs between programmer effort and system overhead,
and avoid the data corruption that input filtering would introduce.

Wietse

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-23 Thread Soenke Ruempler


Hi Rasmus,

On 03/23/2008 04:14 PM, Rasmus Lerdorf wrote:

It is, but it is magic_quotes done right.  You apply a really strict 
filter that makes your data safe for display and your backend by 
default.  The only place you can reliably do this this is at the point 
the data enters your system.  Once it is in, having to remember to apply 
a filter before you use the data will never work.  You might remember to 
do it 99.99% of the time, but that doesn't help you and you might as 
well not do it at all.  A bit like a condom with just one little hole.


Well, my point is: at the stage where user generated data enter your 
program you don't know for which subsystem to prepare it. Maybe for one, 
maybe for more of them (it's a common case that user input is first 
written to SQL backend and then displayed again).


So if everything is html escaped with the filter extension and I wanna 
put it into SQL I have to remember "ah all my input is escaped for html 
so I have to DECODE it and then prepare it to go into SQL". Now the 
question is: What's easier, more intuitive and less headaching?


I guess the real challange is not to try to do as much as possible magic 
by PHP but


a) to give users a simple way for escaping their data for the particular 
subsystem
b) to point them to the right solution within the manual. (addslashes is 
bad for sql, parameter binding / prepared statement is nice - echo is 
bad for html output, htmlspecialchars or a newly intoduced short-tag is 
nice).


-soenke

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Soenke Ruempler wrote:

Hi Rasmus,

On 03/23/2008 03:32 PM, Rasmus Lerdorf wrote:

This is what the filter extension is for.  You should be working with 
escaped data by default and only poke a hole in your data firewall in 
the few places where you need to work with the raw data.  Doing it the 
other way around is going to lead to all sorts of security issues.


Mhm. Isn't the the right paradigm to prepare variables at the time they 
are passed into subsystems (sql, shell, html etc.)? So what do you mean 
with "escaped data" here? html/xml escaped, sql escaped (which sql 
system and which encoding?). Sounds a bit like magic_quotes reloaded 
*hides*


It is, but it is magic_quotes done right.  You apply a really strict 
filter that makes your data safe for display and your backend by 
default.  The only place you can reliably do this this is at the point 
the data enters your system.  Once it is in, having to remember to apply 
a filter before you use the data will never work.  You might remember to 
do it 99.99% of the time, but that doesn't help you and you might as 
well not do it at all.  A bit like a condom with just one little hole.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-23 Thread Soenke Ruempler


Hi Rasmus,

On 03/23/2008 03:32 PM, Rasmus Lerdorf wrote:

This is what the filter extension is for.  You should be working with 
escaped data by default and only poke a hole in your data firewall in 
the few places where you need to work with the raw data.  Doing it the 
other way around is going to lead to all sorts of security issues.


Mhm. Isn't the the right paradigm to prepare variables at the time they 
are passed into subsystems (sql, shell, html etc.)? So what do you mean 
with "escaped data" here? html/xml escaped, sql escaped (which sql 
system and which encoding?). Sounds a bit like magic_quotes reloaded *hides*


IMHO a short syntax for echoing data html-escaped would be very helpful 
and a great extension to the language. If people (esp. newbies) are 
pointed to this one instead of echo/print for echo'ing html parts it 
could lead to a big win for php application security.


-soenke

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Jared Williams wrote:

-Original Message-
From: Stefan Walk [mailto:[EMAIL PROTECTED] 
Sent: 23 March 2008 11:08

To: Jared Williams
Cc: 'PHP Internals'
Subject: Re: [PHP-DEV] short_open_tag

Jared Williams schrieb:

Well, it's the same as the "but i can't validate my php 
source with xmllint" folks: You're doing it at the wrong 
point. Escaping should happen at the point where you assign 
the var as a temlate var (in my small template class: 
$tpl->assign('items', $some_data) will escape all "leaves" in 
the  data $some_data). This way you don't have to type it 
everytime, you don't have to read it everytime and - best of 
all - you can't forget to do it, so introducing a XSS 
vulnerability is much less likely.

Regards,
Stefan

A lot of people don't use templates, just raw PHP. So having a short tag
escaping would decrease XSS vulnerabilities.

I don't understand why need to essentially duplicate all the variables just
to provide proper escaping. 

This is what the filter extension is for.  You should be working with 
escaped data by default and only poke a hole in your data firewall in 
the few places where you need to work with the raw data.  Doing it the 
other way around is going to lead to all sorts of security issues.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-23 Thread Marcus Boerger

Hello Jared,

Sunday, March 23, 2008, 1:57:20 PM, you wrote:

>  

>> -Original Message-
>> From: Stefan Walk [mailto:[EMAIL PROTECTED] 
>> Sent: 23 March 2008 11:08
>> To: Jared Williams
>> Cc: 'PHP Internals'
>> Subject: Re: [PHP-DEV] short_open_tag
>> 
>> Jared Williams schrieb:
>> > 
>> > 
>> > 
>> > 
>> > 
>> 
>> Well, it's the same as the "but i can't validate my php 
>> source with xmllint" folks: You're doing it at the wrong 
>> point. Escaping should happen at the point where you assign 
>> the var as a temlate var (in my small template class: 
>> $tpl->assign('items', $some_data) will escape all "leaves" in 
>> the  data $some_data). This way you don't have to type it 
>> everytime, you don't have to read it everytime and - best of 
>> all - you can't forget to do it, so introducing a XSS 
>> vulnerability is much less likely.
>> 
>> Regards,
>> Stefan

> A lot of people don't use templates, just raw PHP. So having a short tag
> escaping would decrease XSS vulnerabilities.

> I don't understand why need to essentially duplicate all the variables just
> to provide proper escaping. 

Same here. PHP itself is the templating system. And we should focus on that
one. Becasue that is the vast majority of users. However we shouldn't make
other stuff harder than necessary. That said, I more and more think we need
to revisit our tags. XML Allows ':' and '_' in names. And As Jared just
wrote one of the things very often done is html escaping in short output.
So i'd like to see the following:
http://www.php.net/unsub.php

RE: [PHP-DEV] short_open_tag

2008-03-23 Thread Jared Williams

 

> -Original Message-
> From: Stefan Walk [mailto:[EMAIL PROTECTED] 
> Sent: 23 March 2008 11:08
> To: Jared Williams
> Cc: 'PHP Internals'
> Subject: Re: [PHP-DEV] short_open_tag
> 
> Jared Williams schrieb:
> > 
> > 
> > 
> > 
> > 
> 
> Well, it's the same as the "but i can't validate my php 
> source with xmllint" folks: You're doing it at the wrong 
> point. Escaping should happen at the point where you assign 
> the var as a temlate var (in my small template class: 
> $tpl->assign('items', $some_data) will escape all "leaves" in 
> the  data $some_data). This way you don't have to type it 
> everytime, you don't have to read it everytime and - best of 
> all - you can't forget to do it, so introducing a XSS 
> vulnerability is much less likely.
> 
> Regards,
> Stefan

A lot of people don't use templates, just raw PHP. So having a short tag
escaping would decrease XSS vulnerabilities.

I don't understand why need to essentially duplicate all the variables just
to provide proper escaping. 

Jared


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Jared Williams schrieb:








Well, it's the same as the "but i can't validate my php source with 
xmllint" folks: You're doing it at the wrong point. Escaping should 
happen at the point where you assign the var as a temlate var (in my 
small template class: $tpl->assign('items', $some_data) will escape all 
"leaves" in the  data $some_data). This way you don't have to type it 
everytime, you don't have to read it everytime and - best of all - you 
can't forget to do it, so introducing a XSS vulnerability is much less 
likely.


Regards,
Stefan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Steph Fox


Oh and ps


1. Leave it as is and be in World of Configuration Pain (TM)
2. Allow guys)


This is the way I understood Johannes' proposal - shoot me if I'm wrong 
here Johannes.


But I don't have the means of testing to hand, so I'm willing/expecting to 
be told why this is a bad idea by those that do.


and I also agree with Johannes' point that any change here should be in PHP 
6, regardless.


- Steph


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Rasmus Lerdorf


Stanislav Malyshev wrote:
I see your point... but wouldn't it be better not to need that? 
Johannes' idea seemed good to me, always assuming it's do-able.


Well, yes, it would indeed, but we have a lot of either we allow with it I might be OK too, as IMO no valid XML would have some other syntax - in which case a) it probably would be worse than since you hardly can get shorter and "opening tag + =" is kind-of 
de-facto standard for such things by now and b) it's take time to 
educate people to use new syntax, especially that unlike work on PHP < 5.3 so people would stay away from it for a couple of 
years (heck, people still use PHP 4 out there! not talking about 5.0).


So we have this:
1. Leave it as is and be in World of Configuration Pain (TM)
2. Allow guys)


I'd be ok with that too.  It's not a valid PI tag, as far as I know, but 
I don't think that is a problem.


One interesting observation is that there was a slight BC break related 
to short tags between PHP 4 and 5 that I hadn't noticed before.




Works in PHP4 but results in a syntax error in PHP 5.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Steph Fox


Hi Stas,


1. Leave it as is and be in World of Configuration Pain (TM)
2. Allow guys)


This is the way I understood Johannes' proposal - shoot me if I'm wrong here 
Johannes.


But I don't have the means of testing to hand, so I'm willing/expecting to 
be told why this is a bad idea by those that do.


- Steph


3. Invent some http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED] 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Stanislav Malyshev

I see your point... but wouldn't it be better not to need that? 
Johannes' idea seemed good to me, always assuming it's do-able.


Well, yes, it would indeed, but we have a lot of either we allow with it I might be OK too, as IMO no valid XML would have some other syntax - in which case a) it probably would be worse than since you hardly can get shorter and "opening tag + =" is kind-of 
de-facto standard for such things by now and b) it's take time to 
educate people to use new syntax, especially that unlike work on PHP < 5.3 so people would stay away from it for a couple of 
years (heck, people still use PHP 4 out there! not talking about 5.0).


So we have this:
1. Leave it as is and be in World of Configuration Pain (TM)
2. Allow guys)

3. Invent some http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Steph Fox


Hi Stas,


  you can already do all you want. We do not have to make it more complex
at all. Ini setting short_open_tags is defined as PHP_INI_PER_DIR, so all
you guys have to do is provide the right configuration, that's all. And 
if


Ok, here we go again: this setting is needed to enable people to work BOTH 
with short tag templates AND in context when short tags can not be turned 
on by system configuration (by technical, administrative or whatever 
reason). We want to make it work WITHOUT requiring to change system 
configuration, exactly for the reason that it would work in ANY system 
configuration and WOULD NOT require any administrative work.


I see your point... but wouldn't it be better not to need that? Johannes' 
idea seemed good to me, always assuming it's do-able.


- Steph


--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
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

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Stanislav Malyshev


  you can already do all you want. We do not have to make it more complex
at all. Ini setting short_open_tags is defined as PHP_INI_PER_DIR, so all
you guys have to do is provide the right configuration, that's all. And if


Ok, here we go again: this setting is needed to enable people to work 
BOTH with short tag templates AND in context when short tags can not be 
turned on by system configuration (by technical, administrative or 
whatever reason). We want to make it work WITHOUT requiring to change 
system configuration, exactly for the reason that it would work in ANY 
system configuration and WOULD NOT require any administrative work.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] short_open_tag

2008-03-22 Thread Jared Williams

 

> -Original Message-
> From: Stefan Walk [mailto:[EMAIL PROTECTED] 
> Sent: 22 March 2008 22:52
> To: 'PHP Internals'
> Subject: Re: [PHP-DEV] short_open_tag
> 
> Johannes Schlüter schrieb:
> > Now we have the big issue: Do we want to have short open 
> tags forever?
> > Well, without tooo much thinking my idea would be to drop " > keep " same file, 
> > but make it simple to do templating using PHP, on the other 
> hand when 
> > not echo'ing stuff you already have to write more soo the four 
> > additional characters ("php ") don't matter that much - especially 
> > every decent editor/ide should be able to give you a 
> completion on that, if you want.
> 
> 
> 
> 
> 
> 

The problem I have with 





So  imo.

J


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Marcus Boerger

Hello Gregory,

Sunday, March 23, 2008, 12:13:20 AM, you wrote:

> Stefan Walk wrote:
>> Johannes Schlüter schrieb:
>>> Now we have the big issue: Do we want to have short open tags forever?
>>> Well, without tooo much thinking my idea would be to drop ">> ">> make it simple to do templating using PHP, on the other hand when not
>>> echo'ing stuff you already have to write more soo the four additional
>>> characters ("php ") don't matter that much - especially every decent
>>> editor/ide should be able to give you a completion on that, if you want.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> you can have short stuff without outputting stuff too.

> I see many good reasons to disable short open tags.  However, there is a
> compromise that is better from all vantage points:

> 
> 
> 
> 
> 

>  Also legal is  though, this is not so important to me, my primary concern is the
> conflict with  actually do care about writing scripts that are xml-compliant for some
> strange reason :).  Also possible and relatively simple to implement
> would be to allow an = at the start of an expression to alias to T_ECHO,
> so that  would work like .  This is, however,
> very perl-ish, so I mention it only as a possible way to preserve that
> aspect of short tags for template usage.  God forbid we start seeing
> regular scripts using "=" to mean "echo" :).

> As a note, I use exclusively  generate xhtml, so I am very much against per-script enabling of short
> tag  the top of each template and the bottom as well to be a good citizen and
> restore the old value.

To me this sounds more like we were heading towards 'http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Gregory Beaver

Stefan Walk wrote:
> Johannes Schlüter schrieb:
>> Now we have the big issue: Do we want to have short open tags forever?
>> Well, without tooo much thinking my idea would be to drop "> "> make it simple to do templating using PHP, on the other hand when not
>> echo'ing stuff you already have to write more soo the four additional
>> characters ("php ") don't matter that much - especially every decent
>> editor/ide should be able to give you a completion on that, if you want.
> 
> 
> 
> 
> 
> 
> 
> you can have short stuff without outputting stuff too.

I see many good reasons to disable short open tags.  However, there is a
compromise that is better from all vantage points:

 would work like .  This is, however,
very perl-ish, so I mention it only as a possible way to preserve that
aspect of short tags for template usage.  God forbid we start seeing
regular scripts using "=" to mean "echo" :).

As a note, I use exclusively http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Stefan Walk


Johannes Schlüter schrieb:

Now we have the big issue: Do we want to have short open tags forever?
Well, without tooo much thinking my idea would be to drop "







you can have short stuff without outputting stuff too.

Regards,
Stefan

P.S.
This patch will be the most useful addition to PHP that has been added 
for a long time, provided the purists and 
i-don't-know-how-to-write-testcases-the-right-way folks don't succeed in 
shooting it down.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Johannes Schlüter

Hi,

On Fri, 2008-03-21 at 21:13 +0100, Marcus Boerger wrote:
> Hello Stanislav,
> 
> Friday, March 21, 2008, 9:08:02 PM, you wrote:
> 
> >> However the ' >> like ' 
> >  > trouble. If we had something short and nice like  > would make PHP templates look clean, but doing  >  
> The thing is that  And if you ronly argument is saving a few keystrokes then we should really
> get rid of short open tags completely. And definitively not making their
> use easier.

You don't need a ; in front of the ?> therefore 
works, so the only thing " can work quite
nice in simple templating stuff ("PHP is a templating language")

I also think that there aren't many people who preprocess "PHP Hypertext
preprocessor" files with XML-Tools, and if they do they won't use http://google.com/codesearch?hl=en&lr=&q=lang%3Aphp+%3C%5C%3Fphp
+echo+%5B%22%27%5D%3C%5C%3Fxml&btnG=Search>
[2] 



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Marcus Boerger

Hello Lars, Stas,

  you can already do all you want. We do not have to make it more complex
at all. Ini setting short_open_tags is defined as PHP_INI_PER_DIR, so all
you guys have to do is provide the right configuration, that's all. And if
you guys ship your templates then simply remember to ship the configuration
in the template dirs as well (.thaccess). In PHP 5.3 you can even do that
per dir in php.ini.

marcus

Saturday, March 22, 2008, 1:36:36 PM, you wrote:

> Hi Pierre,

> Am Samstag, den 22.03.2008, 13:27 +0100 schrieb Pierre Joye:
> [...]
>> It seems to be very hard to understand that it is not so simple. If
>> this feature is added, every library/module write will have to take
>> care of the short tags if they like to work smoothly in any unknown
>> configuration at runtime. The check is now done (in many cases) during
>> the installation phase and the install script asks the user to disable
>> the short tags to install and run the application or library. If
>> Zend_View or Solar_View use short tags (even worst if they require
>> them), they must be the exceptions in any recent/decent frameworks.

> They do not require them, as their "templating" mechanism is as simple
> as including a PHP file. So it depends on the runtime settings if this
> PHP file can be evaluated properly.

>> The problem with this feature is that the setting can be changed at
>> runtime, anytime. It is yet another pain a la magic quotes GPC and
>> other things like register globals. You said:

> Normally, it doesn't matter if short tags are enabled or not. In some
> cases it is important to have them disabled (the XML example) and in
> some cases it is important to have them enabled (the simple templating
> example). So the component which does XML validation can simply disable
> it while the templating component enables it. The rest should simply
> work with both.

>> "the only way to use short tags is to globally enable them."
>> 
>> That's not the case anymore with this patch and that's why we don't
>> like it...

> I understood that. And that's the reason I like the patch :)

> cu, Lars



Best regards,
 Marcus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Lars Strojny

Hello Pierre,

Am Samstag, den 22.03.2008, 13:17 +0100 schrieb Pierre Joye:
[...]
> Read: Code validation (like in pre commit rules), is one common usage.

Where? I've just never seen any project that does XML validation on XML
templates as a pre-commit rule.

> Think about xml being XML data or HTML. Nothing prevents one to write
> valid (x)html in a valid xml format.

Again: there is no point in validating at a pre-interpreted XML files
(if they contain interpretable code).

> And again this exact example was a proof to a *wrong* claim, it has to
> be extended to be applicable to a real life context. 

Making the example longer (aka "applicable to a real life context"?)
would not change the common characteristics. My claim is, that a
pre-interpreted XML file with PHP instructions can't be reliably
validated anyway, so their is no reason bothering with it. 

> This small but obvious example is not a real life context but only
> (and only!) the proof that Stan's claim was wrong, period.

I'm not sure to which claim you are referring, but I'm not Stas advocate
so this might be true :)

cu, Lars


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Lars Strojny

Hi Pierre,

Am Samstag, den 22.03.2008, 13:27 +0100 schrieb Pierre Joye:
[...]
> It seems to be very hard to understand that it is not so simple. If
> this feature is added, every library/module write will have to take
> care of the short tags if they like to work smoothly in any unknown
> configuration at runtime. The check is now done (in many cases) during
> the installation phase and the install script asks the user to disable
> the short tags to install and run the application or library. If
> Zend_View or Solar_View use short tags (even worst if they require
> them), they must be the exceptions in any recent/decent frameworks.

They do not require them, as their "templating" mechanism is as simple
as including a PHP file. So it depends on the runtime settings if this
PHP file can be evaluated properly.

> The problem with this feature is that the setting can be changed at
> runtime, anytime. It is yet another pain a la magic quotes GPC and
> other things like register globals. You said:

Normally, it doesn't matter if short tags are enabled or not. In some
cases it is important to have them disabled (the XML example) and in
some cases it is important to have them enabled (the simple templating
example). So the component which does XML validation can simply disable
it while the templating component enables it. The rest should simply
work with both.

> "the only way to use short tags is to globally enable them."
> 
> That's not the case anymore with this patch and that's why we don't
> like it...

I understood that. And that's the reason I like the patch :)

cu, Lars


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Pierre Joye

Hi Lars,

On Sat, Mar 22, 2008 at 1:09 PM, Lars Strojny <[EMAIL PROTECTED]> wrote:

>  Providing the infrastructure to enable/disable short tags per runtime
>  allows people to better define their API, in this case the API for
>  templating as they can define "the only point where one may use short
>  tags, are the templates". Currently, if people want short tags, and they
>  want to use it (see Solar_View or Zend_View from the Solar resp. Zend
>  Framework), the only way to use short tags is to globally enable them.
>  So please, just leave the patch in, and do not use short tags, if you
>  dislike them.

It seems to be very hard to understand that it is not so simple. If
this feature is added, every library/module write will have to take
care of the short tags if they like to work smoothly in any unknown
configuration at runtime. The check is now done (in many cases) during
the installation phase and the install script asks the user to disable
the short tags to install and run the application or library. If
Zend_View or Solar_View use short tags (even worst if they require
them), they must be the exceptions in any recent/decent frameworks.

The problem with this feature is that the setting can be changed at
runtime, anytime. It is yet another pain a la magic quotes GPC and
other things like register globals. You said:

"the only way to use short tags is to globally enable them."

That's not the case anymore with this patch and that's why we don't like it...

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Pierre Joye

Hi,

On Sat, Mar 22, 2008 at 1:09 PM, Lars Strojny <[EMAIL PROTECTED]> wrote:
> Hi Ralph, Pierre, everybody,
>
>  Am Samstag, den 22.03.2008, 01:23 +0100 schrieb Pierre Joye:
>
> > On Sat, Mar 22, 2008 at 12:51 AM, Ralph Schindler <[EMAIL PROTECTED]> wrote:
>  > >
>  > >  > Take this file:
>  > >  >
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  >
>  > >  > and run it through xmllint.
>
>  That's exactly the point, thanks Ralph. It makes absolutely no sense
>  validating XML documents containing PHP instructions *before* the
>  instructions have been processed

Read: Code validation (like in pre commit rules), is one common usage.
Think about xml being XML data or HTML. Nothing prevents one to write
valid (x)html in a valid xml format.

And again this exact example was a proof to a *wrong* claim, it has to
be extended to be applicable to a real life context. This small but
obvious example is not a real life context but only (and only!) the
proof that Stan's claim was wrong, period.

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Lars Strojny

Hi Ralph, Pierre, everybody,

Am Samstag, den 22.03.2008, 01:23 +0100 schrieb Pierre Joye:
> On Sat, Mar 22, 2008 at 12:51 AM, Ralph Schindler <[EMAIL PROTECTED]> wrote:
> >
> >  > Take this file:
> >  >
> >  > 
> >  > 
> >  > 
> >  > 
> >  >
> >  > and run it through xmllint.

That's exactly the point, thanks Ralph. It makes absolutely no sense
validating XML documents containing PHP instructions *before* the
instructions have been processed as the instructions may - obviously -
change the state of the document (e.g. . So a much more sensible QA
practice is to generate the process the template and validate it after
processing (at least in the development stage). At this time, no matter
which tags have been used, and only at this time, it is possible to
determine whether a document can be counted valid or not.

Example 1 (not valid before processing):

Example 2 (valid before processing but not after):

";?>

Example 3 (valid before an after processing):

I've picked three random use cases. Only one of them can be successfully
validated before processing.
Rasmus pointed it out before, people are using short tags, because they
want to save keystrokes and increase readability. More verbose code
(using temporary variables, etc. pp.) might be better in business logic
but the quality of a template rises and sinks with the size of its
instructions. This is why people do use Smarty ({foreach from=$array
item=item} is shorter than 

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Lester Caine

Rasmus Lerdorf wrote:
There are a bunch of factors here. In the end it comes down to the
purists vs. the pragmatists. You all know where I fall on that one.

Now, someone mentioned the purist side. A PI tag is defined as and I am
pretty sure the PI label names can't contain '='. adopted in order to be correct, let's not break that correctness.

I think I'm a purist pragmatist ;)

I HAVE been moving to Having just taken a close look at the differences, the main thing is that all
the old code has lots of in line html and adding 'php' everywhere ( actually
4500 hits ) will make it even more difficult to read. However *I* am the only
person using that code, and simply remembering to switch back on short tags on
a new installation allows the old stuff to work.

All my new work is going via bitweaver and I was a little surprised to find
only 10 pump out the html. And most of those seem to be either mistakes - 'are actually in SQL - and wrong :)

An hour ago I would have said I needed since *I* am being dragged the right way by the other bitweaver members - will become a thing of the past for me. HOWEVER quick and dirty pages will no
doubt come out of the shop here simply because there are so many quite complex
pages in the archive and I'm not sure a global convert - while easy to do - is
appropriate.

Bottom line. Global does not work for me - yet, directory level does and I
can't see any logical reason now for switching on and off at will. If it's in
a short tag directory that will do for me - now I just need to actually do that :)

--
Lester Caine - G8HFL
-
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Steph Fox


Hi Andrés/Rob,

as usual my >> are playing up so I'll use ==

=
I'm new to the internals, but I've been reading you for months... now, let 
me

ask,

Are there any security issues with short tags?
Is it really harder for the interpreter to have them enabled?
Is the short tags parsing code too hard to maintain?
Do they create a performance hit?
Do they create bad habits, why?
Does the patch for ini_set create a performance issue?
What ACTUAL situation makes you hate short tags? What code are you using to 
do

what such that you find short tags being evil?
Isn't it that you just don't like them, or don't like reading them in PHP 
code?


I personally hate , but I like and use , it's just much more 
readable
and concise than . What if the parser would ignore or

system I've had to deal with is using them and every MVC framework out there 
is

using short tags for the views. And they only represent an issue if you have
some XML code you send through the PHP parser, and you can always use a
global/per-dir setting if you just don't like them.

+1 for the patch (if it doesn't create a performance or maintainability 
issue)
+1 to keep short tags into PHP (deprecate them if you want, but only remove 
them

in PHP 7 and provide a suitable alternative)
===

The problem is that if you have more than one application to deal with and 
one uses short_tags and the next does not, the second can be screwed up by 
it. Hence the widespread hysteria at the idea of making short_tags even 
easier to switch on.


And as I write that I find 28 new questions of my own :)

- Steph


Regards,

Rob

Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE: bestplace 
|

Web: bestplace.biz | Web: seo-diy.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

RE: [PHP-DEV] short_open_tag

2008-03-21 Thread Andrés Robinet

> -Original Message-
> From: Pierre Joye [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 21, 2008 8:30 PM
> To: Rasmus Lerdorf
> Cc: Elizabeth M Smith; internals@lists.php.net
> Subject: Re: [PHP-DEV] short_open_tag
> 
> Hi Rasmus,
> 
> On Sat, Mar 22, 2008 at 1:20 AM, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> 
> >  Will actually do about the same thing in the sense that the top-level
> >  script can run with short_open_tag turned off and the main.php script
> >  can run with short_open_tag enabled.  The first version requires that
> >  you configure your Apache to enable short_open_tag for the templates/
> >  directory, while the second lets you do it from the PHP level.  The
> >  first suffers from being extremely slow and it isn't obvious that
> >  scripts in templates/ operate under different rules.  The second is much
> >  faster and it is more obvious what is happening.
> 
> as a conclusion from my point of view, I don't think it's possible to
> bring anything new to this dicsussion:
> 
> -1 for the patch (revert)
> +1 to actually deprecate short tags
> +1 to remove them in HEAD
> 
> That's not asked but let clear this problem once and for all.
> 
> Cheers,
> --
> Pierre
> http://blog.thepimp.net | http://www.libgd.org

Hi,

I'm new to the internals, but I've been reading you for months... now, let me
ask,

Are there any security issues with short tags?
Is it really harder for the interpreter to have them enabled?
Is the short tags parsing code too hard to maintain?
Do they create a performance hit?
Do they create bad habits, why?
Does the patch for ini_set create a performance issue?
What ACTUAL situation makes you hate short tags? What code are you using to do
what such that you find short tags being evil?
Isn't it that you just don't like them, or don't like reading them in PHP code?

I personally hate , but I like and use , it's just much more readable
and concise than . What if the parser would ignore http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Steph Fox

Elizabeth M Smith wrote:

Wow, noisy...

I've been in the situation where I use php for templating and the short
syntax is much nicer on the eyes. The ability to "flick the switch" for
short tags would be nice.

However, like Steph, I've also been bitten by having a simple xml
declaration in a file with short tags on that completely breaks things.
Parse errors are NOT a good thing. This is why I'd personally prefer
short tags just go poof - having to check all your code so any
appearance of

There are a bunch of factors here. In the end it comes down to the
purists vs. the pragmatists. You all know where I fall on that one. is for the purists and

Now, someone mentioned the purist side. A PI tag is defined as and I am
pretty sure the PI label names can't contain '='. adopted in order to be correct, let's not break that correctness.

Most of the arguments I have seen are basically saying shouldn't even exist, but that isn't the current question. It does exist,
and we aren't removing it, so the only real argument here is the WTF
factor introduced by code that is able to enabled or disable these tags on
the fly. That's the one and only valid argument I have seen. Whether or
not PHP code can be validated with xmllint and whether or not xml, which it obviously isn't, is completely beside the point. We all
know that when you use majority that's ok. XHTML is dead because IE, which is unfortunately the
dominant browser has never and never will support XHTML. Yes, you can
hack it and serve up XHTML with an HTML mime type and apply various hacks
to sort of almost maybe sometimes get it to work in IE, but nobody who
does any serious web development uses XHTML for sites that have wide
audiences.

So, we are down to a very simple decision. Does the added WTF factor of
dynamically changing short_open_tags outweigh the benefits to the folks
using

My view is that people want templating. As much as I hate the concept,
and have always been very vocal about that, people want simpler templating
tags. They will even go as far as parsing files and generating PHP code
on every single request in order to use {blah} instead of .
The fact that people are willing to take an order of magnitude performance
hit for syntactic sugar is baffling to me, but just look at all the
templating systems out there. And yes, I know there are other reasons to
use templating such as restricting the feature set for untrusted template
writers, etc. but you'd be surprised how many people just want to type
less and have their tags be prettier. Getting these folks to switch to
is a win for performance and sanity in my book. Yes, it isn't
a full victory, but it is still a win.

In order for a templating system to use short_open_tag on for the entire system. By allowing them to only apply
the short_open_tags to certain parts of their code it means that they will
write correct the actual included template files. Again, not a full victory, but a win
for us in the sense that the actual PHP code in their application will be
using business logic because it won't work due to limiting the short_open_tags
to just the templates.

I recognize the WTF factor of dynamically changing the setting, but
frankly since it can already be changed per-dir from one request to the
next on the same server, I really don't see the incremental WTF factor as
being very high.

Consider the fact that:

and

Will actually do about the same thing in the sense that the top-level
script can run with short_open_tag turned off and the main.php script can
run with short_open_tag enabled. The first version requires that you
configure your Apache to enable short_open_tag for the templates/
directory, while the second lets you do it from the PHP level. The first
suffers from being extremely slow and it isn't obvious that scripts in
templates/ operate under different rules. The second is much faster and
it is more obvious what is happening.

Ok here's a stupid suggestion.

Is it at all possible to turn off (for all time) short_tags in php.ini BUT
allow scripts that want to use short-tags to explicitly use them via
ini_set()?

It might mean a lot of re-thinking... and yes I do know it's not currently
an option :)

- Steph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hi Rasmus,

On Sat, Mar 22, 2008 at 1:20 AM, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:

>  Will actually do about the same thing in the sense that the top-level
>  script can run with short_open_tag turned off and the main.php script
>  can run with short_open_tag enabled.  The first version requires that
>  you configure your Apache to enable short_open_tag for the templates/
>  directory, while the second lets you do it from the PHP level.  The
>  first suffers from being extremely slow and it isn't obvious that
>  scripts in templates/ operate under different rules.  The second is much
>  faster and it is more obvious what is happening.

as a conclusion from my point of view, I don't think it's possible to
bring anything new to this dicsussion:

-1 for the patch (revert)
+1 to actually deprecate short tags
+1 to remove them in HEAD

That's not asked but let clear this problem once and for all.

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

On Sat, Mar 22, 2008 at 12:46 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:

>  > I often use xmllint or other w3c tools to verify that my xml/xhtml
>  > code is valid, before being parsed by php:
>
>  Right, so _you_ are using XML templates. Don't do short tags then. Many
>  other people, however, use HTML templates, and they are OK and actually
>  want to use short tags.

Don't personalize this discussion, it is not _me_ but many. Don't
ignore this fact, thanks.

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

On Sat, Mar 22, 2008 at 12:51 AM, Ralph Schindler <[EMAIL PROTECTED]> wrote:
>
>  > Take this file:
>  >
>  > 
>  > 
>  > 
>  > 
>  >
>  > and run it through xmllint.
>  >
>  > Can we now stop this discussion and revert this patch?
>  >
>
>  Take this file:
>
>  
>  
>  "; ?>
>  
>
>  and run it through your xmllint.
>
>  Passes right?  Does that mean its valid xml/xhtml on the flip side? No,
>  it wont pass.
>
>  Is XML Spec compliancy a goal of the PHP Project?


It was an answer to a wrong claim. Don't create wrong conclusions out
of my post, thanks.


-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Rasmus Lerdorf

Elizabeth M Smith wrote:

Wow, noisy...

I've been in the situation where I use php for templating and the short
syntax is much nicer on the eyes. The ability to "flick the switch" for
short tags would be nice.

There are a bunch of factors here. In the end it comes down to the
purists vs. the pragmatists. You all know where I fall on that one.

Now, someone mentioned the purist side. A PI tag is defined as and I am
pretty sure the PI label names can't contain '='. adopted in order to be correct, let's not break that correctness.

Most of the arguments I have seen are basically saying shouldn't even exist, but that isn't the current question. It does
exist, and we aren't removing it, so the only real argument here is the
WTF factor introduced by code that is able to enabled or disable these
tags on the fly. That's the one and only valid argument I have seen.
Whether or not PHP code can be validated with xmllint and whether or not
point. We all know that when you use for the vast majority that's ok. XHTML is dead because IE, which is
unfortunately the dominant browser has never and never will support
XHTML. Yes, you can hack it and serve up XHTML with an HTML mime type
and apply various hacks to sort of almost maybe sometimes get it to work
in IE, but nobody who does any serious web development uses XHTML for
sites that have wide audiences.

So, we are down to a very simple decision. Does the added WTF factor of
dynamically changing short_open_tags outweigh the benefits to the folks
using

My view is that people want templating. As much as I hate the concept,
and have always been very vocal about that, people want simpler
templating tags. They will even go as far as parsing files and
generating PHP code on every single request in order to use {blah}
instead of . The fact that people are willing to take an
order of magnitude performance hit for syntactic sugar is baffling to
me, but just look at all the templating systems out there. And yes, I
know there are other reasons to use templating such as restricting the
feature set for untrusted template writers, etc. but you'd be surprised
how many people just want to type less and have their tags be prettier.
Getting these folks to switch to is a win for performance
and sanity in my book. Yes, it isn't a full victory, but it is still a win.

In order for a templating system to use short_open_tag on for the entire system. By allowing them to only apply
the short_open_tags to certain parts of their code it means that they
will write correct for the actual included template files. Again, not a full victory, but
a win for us in the sense that the actual PHP code in their application
will be using in their business logic because it won't work due to limiting the
short_open_tags to just the templates.

Consider the fact that:

and

Will actually do about the same thing in the sense that the top-level
script can run with short_open_tag turned off and the main.php script
can run with short_open_tag enabled. The first version requires that
you configure your Apache to enable short_open_tag for the templates/
directory, while the second lets you do it from the PHP level. The
first suffers from being extremely slow and it isn't obvious that
scripts in templates/ operate under different rules. The second is much
faster and it is more obvious what is happening.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Ralph Schindler




Take this file:






and run it through xmllint.

Can we now stop this discussion and revert this patch?



Take this file:



"; ?>


and run it through your xmllint.

Passes right?  Does that mean its valid xml/xhtml on the flip side? No, 
it wont pass.


Is XML Spec compliancy a goal of the PHP Project?

-ralph


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Please (OH! Please!!!) read our answers, read the specs and understand
that many of us (if not the majority) have to work with xhtml or XML.


Working with XML does not requires putting XML through PHP parser. Even 
if it did, with my patch it works better than without - it allows to 
have both HTML templates and XML without needing even to touch 
configurations.



I often use xmllint or other w3c tools to verify that my xml/xhtml
code is valid, before being parsed by php:


Right, so _you_ are using XML templates. Don't do short tags then. Many 
other people, however, use HTML templates, and they are OK and actually 
want to use short tags.



Thanks for your understanding, there is no more argument on any side
and the decision is obvious (by the voices and by the arguments).


No, it is not obvious, unless you take "obvious" to mean "agreeing with 
you".

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

On Fri, Mar 21, 2008 at 10:26 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Yeah, there has been a huge change. A good chunk of that change is XML.
>
>  XML as "parsing XML and working with DOM", not XML as "putting XML
>  through PHP parser".

Please (OH! Please!!!) read our answers, read the specs and understand
that many of us (if not the majority) have to work with xhtml or XML.

> It is very important to understand that no short
>  tags would ever cause you any problems with any XML *unless* you put
>  that XML through PHP parser - which having DOM, SimpleXML, etc. isn't
>  really that needed. Less then ever, I'd say.

Ok, can you at least try what you affirm?

Some tips:
I often use xmllint or other w3c tools to verify that my xml/xhtml
code is valid, before being parsed by php:

Take this file:

and run it through xmllint.

Can we now stop this discussion and revert this patch?

Thanks for your understanding, there is no more argument on any side
and the decision is obvious (by the voices and by the arguments).

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Richard Quadling

On 21/03/2008, Elizabeth M Smith <[EMAIL PROTECTED]> wrote:
> Wow, noisy...
And having made the commit to the dox before the revert, I'm still
reeling/reading to try and see which way I would go...

>  I'd argue that a   the difference" between the ugliness of the long version and the need to
>  not break php every time an xml declaration pops up in a file.  Even
>  gettext has a nice _() function shortcut which is less typing than echo
>  $blah; in every php tag set, and then you wouldn't be fighting with the
>  potential breakage.  The argument that if some new syntax only goes into
>  5.3, people can't use it doesn't really hold water here because you
>  wouldn't be able to rely on flipping the short_tags switch before 5.3
>  either.
>
>  I can see both sides of the story, and really don't have a preference -
>  I'm curious as to the opinions of someone OTHER than Marcus, Stas,
>  Pierre and Jani ;)

If you saw ...


or


what would you assume this meant?

>From this, I would say it isn't a function call as I would need to add () to 
>it.
It is not an assignment or declaration.
If it was documented that a PHP statement consisting of just a
variable name would echo a string, then I think this would solve all
the problems of readability.

What would you assume a non programmer thought of it? If they were
told "this is how you put a PHP variable into a template" would they
just go with it?

Ok, again, I'm no internals expert.

Maybe the _$varname; would be more pleasing.

On the plus side there is only 1 PHP tag. No matter what happens http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Edward Z. Yang

Elizabeth M Smith wrote:
> I'd argue that a  the difference" between the ugliness of the long version and the need to
> not break php every time an xml declaration pops up in a file. 

+1

-- 
 Edward Z. YangGnuPG: 0x869C48DA
 HTML Purifier  Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Elizabeth M Smith

Wow, noisy...

I've been in the situation where I use php for templating and the short
syntax is much nicer on the eyes.  The ability to "flick the switch" for
short tags would be nice.

However, like Steph, I've also been bitten by having a simple xml
declaration in a file with short tags on that completely breaks things.
Parse errors are NOT a good thing.  This is why I'd personally prefer
short tags just go poof - having to check all your code so any
appearance of http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

  well, any XML tool seeing '> Yeah, there has been a huge change. A good chunk of that change is XML.

> XML as "parsing XML and working with DOM", not XML as "putting XML 
> through PHP parser". It is very important to understand that no short 
> tags would ever cause you any problems with any XML *unless* you put 
> that XML through PHP parser - which having DOM, SimpleXML, etc. isn't 
> really that needed. Less then ever, I'd say.



Best regards,
 Marcus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


I haven't seen a single technical argument from your side.


That's just hilarious. I spend entire half-day repeating arguments about 
XML and short tags and templates and users and what not - but why bother 
if Marcus doesn't even read it? Well, I hope at least somebody reads it. 
As for trying to convince people that couldn't care less - I'm close to 
give up talking to those.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

Friday, March 21, 2008, 9:37:51 PM, you wrote:

>>   lemme think, PHP is used to generate HTML and XHTML. And often people

> Neither of which require > have the headers outside of the PHP tags. And some people like to use tools.
>> But maybe I am wrong. Either way. It appears that nearly every single
>> person replying is against this. So can we please stop arguing? I don't

> You mean like 3 people that can't even explain

I think you should take a step back dude.

>> think there are more arguemnts coming. And it doesn't look like you are
>> convincing anyone here.

> Maybe because these "someone" just can't be convinced by rational 
> argument. This is really sad that people are willing to sacrifice 
> interests of the users and the language development for... well, I don't 
> even know for what. For not admitting they were wrong for once?

I haven't seen a single technical argument from your side.

Best regards,
 Marcus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


But maybe the change is that now it is considered evil by an even larger
amount of people.


So far I saw four. I do not double I can find 5 people that like 
templates with short tags. But anyway it doesn't matter much because 
short tags are in PHP 5 and not going anywhere. So the question is do 
you make user's life harder because they disagree with you - or do you 
make them easier to use PHP even when they use it not the same way as 
you do? I think the second way is better.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

This was discussed several times already and Pierre put you directly onto
its definition. What more can we say? I think we have a valid technical

You obviously think so, but it doesn't automatically makes it valid.
Explaining again: PHP code needs to conform to XML standard *only* if
you have files that need to be *both* valid PHP *and* valid XML. Only
files I can imagine that need to be both valid PHP and valid XML are XML
templates that are passed through PHP parser. It is very rare use case -
most of templates are HTML and not XML - and it can be supported even
better with my proposal, since with it you can haver *both* XML
templates *and* HTML templates with short tags in the same application,
without needing any external configuration - while without it you can
have only one working, even with configuration.

argument here, where you seem to simply wanting to save a few key strokes.

Sounds like you miss most of what I write, but I will try again, in hope
this time I manage to squeeze it through. I do not "simply want to save
keystrokes", I want to enable PHP template systems to have functionality
that:
1. Is present in *every* popular templating system, including RoR, ASP,
JSP, Perl::Mason and probably countless others.
2. Makes PHP templates easy to read even for person not knowing PHP
syntax, easy to write and and easy to parse visually.

Now, I see enabling runtime way to do it, since it allows to do the above *without* permanently
disabling even the very rare XML parsing case - you can easily do
templating system that supports both. If there's better way (and
keystroke), then I am willing to consider it.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

Friday, March 21, 2008, 10:19:19 PM, you wrote:

>> http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=1.263
>> guess who made that commit...

> I wish I remembered what the rationale for that was, but of course I 
> don't. Anyway, in 7 years there might be a bit of a change in how people 
> use PHP, and that of course doesn't support the point of short tags 
> being evil in general.

But maybe the change is that now it is considered evil by an even larger
amount of people.

Best regards,
 Marcus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Yeah, there has been a huge change. A good chunk of that change is XML.


XML as "parsing XML and working with DOM", not XML as "putting XML 
through PHP parser". It is very important to understand that no short 
tags would ever cause you any problems with any XML *unless* you put 
that XML through PHP parser - which having DOM, SimpleXML, etc. isn't 
really that needed. Less then ever, I'd say.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

Friday, March 21, 2008, 10:11:24 PM, you wrote:

> Hi!

>>   since when can I not verify that my general HTML/XHTML structure is valid?

> The question is since when PHP code has any XML structure?

>> This is especially valid in template systems as you mentioned earlier.

> OK, so you are verifying templates. Great. Obviously, if you use XML 
> templates (with PHP being Web language, this is rather unusual use case, 
> but OK), you are not using short tags, so it's OK. However, for people 
> having HTML templates, it still would be OK to verify them with HTML 
> tools unless you have tools that OK with  Are there such tools?

http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Hannes Magnusson

On Fri, Mar 21, 2008 at 10:19 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=1.263
>  > guess who made that commit...
>
>  I wish I remembered what the rationale for that was, but of course I
>  don't. Anyway, in 7 years there might be a bit of a change in how people
>  use PHP, and that of course doesn't support the point of short tags
>  being evil in general.

Yeah, there has been a huge change. A good chunk of that change is XML.

-Hannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=1.263
guess who made that commit...


I wish I remembered what the rationale for that was, but of course I 
don't. Anyway, in 7 years there might be a bit of a change in how people 
use PHP, and that of course doesn't support the point of short tags 
being evil in general.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Hannes Magnusson

On Fri, Mar 21, 2008 at 8:11 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>  And if you look at the discussion, there were opinions - including
>  Zeev's - that there's nothing wrong with shorts tags in general, only in
>  some rare use cases.

http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=1.263
guess who made that commit...

-Hannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Hi!


  since when can I not verify that my general HTML/XHTML structure is valid?


The question is since when PHP code has any XML structure?


This is especially valid in template systems as you mentioned earlier.


OK, so you are verifying templates. Great. Obviously, if you use XML 
templates (with PHP being Web language, this is rather unusual use case, 
but OK), you are not using short tags, so it's OK. However, for people 
having HTML templates, it still would be OK to verify them with HTML 
tools unless you have tools that OK with Are there such tools?



Because in fact PHP is a tmeplate system for HTML/XHTML after all. So as


If it were only template system, we'd all use short tags as all other 
templates do - take Ruby, Perl::Mason, ASP or JSP, any of those have 
echo shortcut. None of those are too bothered if it works with XML 
parser either, as far as I can see.



long as I only do easy stuff and avoid generating tags inside php I get
valid XML source.


Wait, so it's not only special case of templates - XML - but special 
case of special case - only templates generating very special kind of 
content. So why the whole language syntax should conform this tiny 
subset of all use cases? I'd think it is much better to do what users 
obviously need - since everybody does it, including all popular template 
systems bare none - and support short tags.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-21 Thread Steph Fox


Hi Stas,

In 99.999% of cases you'd get parse error on first line of the file. I have yet to see any other context where short tags 
wouldn't work. So I don't see - what exactly would "not work or misbehave" 
without giving an error? Can you produce any example of application or 
other real code that would silently misbehave with short tags on but 
behave OK with short tags off?


I had at least five PHP/XML applications that did just that during the PHP 5 
coding contest at Zend back in 5.0 days... Zeev asked me at the time to 
explain it more fully, and I sincerely regret never having made the time to 
look into it properly.


And no I don't still have those applications on my laptop. Sorry. But it's 
as a result of working on that contest that I'm against short-tags full 
stop - I still think they should've been deprecated from 5.0 on.


Not good evidence I know, but that's my tuppence-worth on the subject.

- Steph 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

  since when can I not verify that my general HTML/XHTML structure is valid?
This is especially valid in template systems as you mentioned earlier.
Because in fact PHP is a tmeplate system for HTML/XHTML after all. So as
long as I only do easy stuff and avoid generating tags inside php I get
valid XML source.

marcus

Friday, March 21, 2008, 9:49:55 PM, you wrote:

>> There is also an issue when I want to verify my stuff using XML tools.

> One can't really verify PHP code with XML tools, so what exactly are you 
> verifying - could you explain more on that?

Best regards,
 Marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


There is also an issue when I want to verify my stuff using XML tools.


One can't really verify PHP code with XML tools, so what exactly are you 
verifying - could you explain more on that?

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

Friday, March 21, 2008, 9:32:48 PM, you wrote:

>> PHP works more and more in a multi cultural environment (php, jsp,
>> xml, etc.). One of the goals of a standard is to avoid conflicts,

> Great. So let's see when there could be a conflict. Only way there could 
> be a conflict is when XML is included as PHP source. Now, how frequently 
> one really needs to do that?

There is also an issue when I want to verify my stuff using XML tools.

Best regards,
 Marcus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


  lemme think, PHP is used to generate HTML and XHTML. And often people


Neither of which require 
have the headers outside of the PHP tags. And some people like to use tools.
But maybe I am wrong. Either way. It appears that nearly every single
person replying is against this. So can we please stop arguing? I don't


You mean like 3 people that can't even explain why they hate short tags, 
but just like me to shut up because their opinion can't be wrong? Yeah, 
right.



think there are more arguemnts coming. And it doesn't look like you are
convincing anyone here.


Maybe because these "someone" just can't be convinced by rational 
argument. This is really sad that people are willing to sacrifice 
interests of the users and the language development for... well, I don't 
even know for what. For not admitting they were wrong for once?

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


PHP works more and more in a multi cultural environment (php, jsp,
xml, etc.). One of the goals of a standard is to avoid conflicts,


Great. So let's see when there could be a conflict. Only way there could 
be a conflict is when XML is included as PHP source. Now, how frequently 
one really needs to do that?



buggy behavior or system specific features. PHP works with XML in many
cases, xhtml growing usage is one good example. I'm very surprised to
have to discuss this problem once again in this list.


You sound like it was discussed and the decision was in your favor. 
Well, it wasn't - read the summary I just made from the archives. So if 
you want to declare "case closed" - fine, but it's closed in favor of 
short tags.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


The thing is that 

It is easier to use templates with  then with full PHP syntax, 
they look cleaner. Just look how many other templates use "tag" syntax - 
either {SOMETHING} or <%= SOMETHING %> or some like that. Do you that's 
because they are too stupid or too lazy - or because they listen to the 
users? ASP, JSP and Ruby all have <%=, does it teach us anything about 
people liking short tags?


Look how many examples you short syntax - why is that? Because it looks 
better and easy to read. And the only objection to that is - it's not 
valid XML. OK, it is not valid XML - why should it be? Why should PHP 
programmer work harder and PHP code look worse than Ruby, JSP or ASP - 
just because of arbitrary requirement of XML compliance?

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

  lemme think, PHP is used to generate HTML and XHTML. And often people
have the headers outside of the PHP tags. And some people like to use tools.
But maybe I am wrong. Either way. It appears that nearly every single
person replying is against this. So can we please stop arguing? I don't
think there are more arguemnts coming. And it doesn't look like you are
convincing anyone here.

Maybe instead work on a proposal for something like > I gave you the link to one main explanation, the XML specs. Or what
>> else do you need to explain the problem in the XML context?

> I need to explain why XML specs have any relevance to PHP syntax and why 
> PHP sources should conform to them. Are we coding in XML now? Is 
> everybody using an XML parser to process PHP code? How XML spec is one 
> to dictate what PHP syntax is?



Best regards,
 Marcus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

On Fri, Mar 21, 2008 at 9:05 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > The main reason is that they are not valid processing instructions.
>  > See http://www.w3.org/TR/REC-xml/#sec-pi
>
>  Great, they are also probably not valid S-expressions and not valid
>  phrases in Mandarin. Why they are bad because of that? Is there any
>  requirement for them to be?

PHP works more and more in a multi cultural environment (php, jsp,
xml, etc.). One of the goals of a standard is to avoid conflicts,
buggy behavior or system specific features. PHP works with XML in many
cases, xhtml growing usage is one good example. I'm very surprised to
have to discuss this problem once again in this list.

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

Friday, March 21, 2008, 9:08:02 PM, you wrote:

>> However the '> like '  trouble. If we had something short and nice like  would make PHP templates look clean, but doing  http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Great, they are also probably not valid S-expressions and not valid 
phrases in Mandarin. Why they are bad because of that? Is there any 
requirement for them to be?


The argument being?


Why they are bad because of that? Is there any requirement for them to be?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


I gave you the link to one main explanation, the XML specs. Or what
else do you need to explain the problem in the XML context?


I need to explain why XML specs have any relevance to PHP syntax and why 
PHP sources should conform to them. Are we coding in XML now? Is 
everybody using an XML parser to process PHP code? How XML spec is one 
to dictate what PHP syntax is?

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


Nobody can set memory_limit in a script during runtime. AFAICT.


Why? It's INI_ALL. So is, for example, include_path.


Short tags are language SYNTAX issue. That's why it's different.
You don't get any plain error if they're "on" and something doesn't work.
It just doesn't work or misbehaves.


In 99.999% of cases you'd get parse error on first first line of the file. I have yet to see any other context where short 
tags wouldn't work. So I don't see - what exactly would "not work or 
misbehave" without giving an error? Can you produce any example of 
application or other real code that would silently misbehave with short 
tags on but behave OK with short tags off?

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Hello Stanislav,

Friday, March 21, 2008, 9:05:17 PM, you wrote:

>> The main reason is that they are not valid processing instructions.
>> See http://www.w3.org/TR/REC-xml/#sec-pi

> Great, they are also probably not valid S-expressions and not valid 
> phrases in Mandarin. Why they are bad because of that? Is there any 
> requirement for them to be?

The argument being?

Best regards,
 Marcus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

On Fri, Mar 21, 2008 at 9:02 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:

>  No explanation why it "shows lazyness" or why it's bad except for
>  hinting it's somehow bad for handling XML (which it isn't).

See below.

>  Should I go deeper? Did we use the same search engine? I'm still missing
>  explanation why short tags are bad.

I gave you the link to one main explanation, the XML specs. Or what
else do you need to explain the problem in the XML context?

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


However the '

trouble. If we had something short and nice like would make PHP templates look clean, but doing 
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag


The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-pi


Great, they are also probably not valid S-expressions and not valid 
phrases in Mandarin. Why they are bad because of that? Is there any 
requirement for them to be?

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

The first hits explain quite well why short_open_tag is bad, mmkay.

OK, let's see what we have there:

0. Support for my email, skipping.

1. "The web is a rapidly changing market and standards are being
activley evolved. than Then goes for "include XML as template" case. And Rasmus objecting to
short tags being bad code practice.

2. Proposal for PHP to not parse 4. "We should have warned people not to use short tags years ago." no
explanation why. Explaining why

5. Bug report on short_open_tag

6. "As the XML community expands and more and more scripting languages
(server and client side) are being designed to interoperate,
cross-language compatability (or at least handling) is required." - same
person as 1. Then:
"The short tag standard, and its my recommendation that (in version 5 of the product)
the sort tag option is removed."

No explanation why it "shows lazyness" or why it's bad except for
hinting it's somehow bad for handling XML (which it isn't).

7. "I'm -1 on removing short tags, whether now or for PHP5." from Chris.

8. "Not going to happen, please leave this issue alone." from Zeev.
If you have any doubts, "not going to happen" is removal of the short tags.

9. "1. Removing (and even disabling by default) short tags is not
necessary for all PHP-community." from Antony.

Should I go deeper? Did we use the same search engine? I'm still missing
explanation why short tags are bad. Since you have obviously found it,
could you do me a favor and quickly summarize at least couple of reasons
- omitting the one being "every application must include XML through
parser" as obviously invalid.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

On Fri, Mar 21, 2008 at 8:37 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > I'd rather see 
>  Does be template systems couldn't use it until 5.3 is widely deployed - which
>  means no template system can use it as standard for about 2-3 years at
>  least. Unless we put   but might be a trouble for others.
>
>
>  > I'd even use it myself. But I will not EVER enable the damn short tags
>  > again. And won't allow anyone else doing it either. And speaking of
>
>  What's wrong with short tags, can anybody explain me?

The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-pi

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag