If you think there are a lot of people who want this feature as you propose it, then I won't oppose such implementation. I guess the only thing I wouldn't be able to live with would be a default setting after a fresh PHP install where there is a non-raw filter in place. Beyond that, if there are a whole lot of people who would like to see this feature (you are obviously experienced with situations where such a default filter setting would come in very handy, so I have no doubt there are more people who agree) then I can't oppose it.
But please, don't make the magic_quotes_gpc mistake of having it behave non-raw by default in a fresh php.ini. Please, let the default be "raw" (with of course the possibility for people to change it). Ron "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Ron Korving wrote: > > It's a very weird idea to me to filter out HTML on input, because the only > > place where HTML tags could be abused is in the output. So that's where > > filtering should take place, imho. Maybe it's hard to figure out a way to do > > this the easiest way, but failing to come up with an output filtering idea > > should not result in input filtering "just because it's easier" (which, I'm > > very sorry to say reminds me once again of magic_quotes_gpc... it's much > > easier to define such a rule globally, but you end up with a lot of crap). > > Once again, I am open to other solutions to the problem as stated. I > don't see how an output filter could ever work. You can't exactly > filter out raw html at the output stage since just about every PHP > application ever written spits out HTML. People keep wanting a taint > mode in PHP where user data can't be used for anything until validated > and thus untainted. That would break far more things than this > implementation since every single application would have to be modified > for taint support whereas this approach only requires changes to the > specific places in an application where raw data is required. > > And by the way, the security policy may include other things that aren't > limited to output vulnerabilities like XSS. I might for example never > want null characters coming into my system unless it is a file upload. > I am pretty sure weeding out nulls isn't going to break your code in any > way while at the same time it may very well plug security problems in a > number of places. > > How about if I state it this way. As an application developer you are > not expected to work around local security policies. Checking for and > using the supplied filtering functions would be a good idea since they > are likely faster and more robust than the userspace equivalents. Given > that the hook has been available and documented for 2 years you can't > possibly know what sort of filters are in place today and I can assure > you that your code is unlikely to work in my environment. Having a > standard set of filtering functions available that work in conjunction > with the input filtering hook at least gives you a way to have a chance > at working in my environment. > > -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
