Bug #62032 [Opn]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 User updated by:iamcraigcampbell at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: @anon I agree with many of your sentiments :) Just wanted to point out one thing. The issue of unclosed script tags or other tags would not be a problem assuming the output is escaped which it should be. Therefore if you had "Well I can understand stripping it if there is a closing > somewhere, but if >it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. In that case: (1) Unclosed tags will eat extra page content, breaking page layout. (2) Pages consist of many echo statements. By your logic, "", we need to implement a delayed-choice quantum eraser to make all the parallel universes in which the earlier echo statement occurred cease to exist. >I think it is more expected behavior to display this string as "This is NOT >good!". No. Display what users type. Don't delete text from their posts based on the quirks of what just happens to be the underlying display format on a particular day. Suppose your hypothetical forum also displays posts in another format, e.g., it has a Flash or iPhone-based app, or it tweets posts, or a few years from now we're all using a completely different markup language. Should it then also strip HTML-like tags from all text in perpetuity from all media just because HTML happened to be a relevant format to someone somewhere once upon a time, or should user-submitted text throw integrity to the wind and change depending on what kind of device someone is attempting to use to view it, whether or not that device's markup was invented when the post was made? What if someone is trying to use text that legitimately resembles an HTML tag (it happens), or, more likely, they're trying to quote or talk about HTML -- no filter can handle this. No no no no no. Display what they type and don't confuse the poor souls. I.e., use htmlspecialchars() if outputting to HTML; or if not, use whatever other escaping method is appropriate to the particular output format that still preserves the integrity of the user-typed text in that format, while making exception for the formatting markup that is legitimately supported and documented to be supported by the forum, such as markdown or bbcode syntax (and probably not HTML, since besides the fact that HTML is ugly and over-complicated for most forum post needs, strip_tags with an allowed tags parameter is the most dangerous of the lot and allows blatant abuse via attributes). And don't get me started on entities. tl;dr: no amount of wrapping it in flashy filter functions changes the fact that strip_tags confuses countless souls, is brain-damaged, and ought to be deprecated to death. ---------------- [2012-05-15 15:06:26] iamcraigcampbell at gmail dot com @pajoye I agree with you, but there is a use case that encoding will not solve. Let's say there is a forum where users are posting. If the user posts: "This is NOT good!" and the tags get encoded then that means the HTML tags will be displayed in the forum as plain text. I think it is more expected behavior to display this string as "This is NOT good!". So one option would be encoding the < only if it is not followed by a > but that is a lot of extra work to figure that out. At the end of the day the point is that no matter how you look at it I still think this is a bug. $string = 'This is true: 2<5'; strip_tags($string); and filter_var($string, FILTER_SANITIZE_STRING); Should not strip out <5 since that is not an HTML tag. [2012-05-15 14:51:09] aleksey dot v dot korzun at gmail dot com How is stripping anything after < with a space is a valid operation? That seems like a lazy man's html stripper. Let's just blindly strip everything that can possibly be made into an html tag of any sort. Not. [2012-05-15 14:49:02] paj...@php.net > or < should be encoded then, see http://www.php.net/manual/en/filter.filters.sanitize.php btw, any option should be added using the option array or defaults, as it is the case already. [2012-05-15 14:45:27] iamcraigcampbell at gmail d
Bug #62032 [Com]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 Comment by: iamcraigcampbell at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: @pajoye I agree with you, but there is a use case that encoding will not solve. Let's say there is a forum where users are posting. If the user posts: "This is NOT good!" and the tags get encoded then that means the HTML tags will be displayed in the forum as plain text. I think it is more expected behavior to display this string as "This is NOT good!". So one option would be encoding the < only if it is not followed by a > but that is a lot of extra work to figure that out. At the end of the day the point is that no matter how you look at it I still think this is a bug. $string = 'This is true: 2<5'; strip_tags($string); and filter_var($string, FILTER_SANITIZE_STRING); Should not strip out <5 since that is not an HTML tag. Previous Comments: [2012-05-15 14:51:09] aleksey dot v dot korzun at gmail dot com How is stripping anything after < with a space is a valid operation? That seems like a lazy man's html stripper. Let's just blindly strip everything that can possibly be made into an html tag of any sort. Not. [2012-05-15 14:49:02] paj...@php.net > or < should be encoded then, see http://www.php.net/manual/en/filter.filters.sanitize.php btw, any option should be added using the option array or defaults, as it is the case already. ---------------- [2012-05-15 14:45:27] iamcraigcampbell at gmail dot com So in that case I think strip_tags and filter_var are both broken. In this context: "It is true that 5<10" "It is true that 5 < 10" Neither of these are html tags so the string should not be touched regardless of if there is a space or not. [2012-05-15 14:42:47] reeze dot xia at gmail dot com PS: the reason why strip_tags() didn't strip it is '<' is followed by a space char but not without ending '>', this is the key point. look deep into the source code, there difference is switch whether or not to trait '<' followed by a(or more) spaces a tag or not. [2012-05-15 14:36:26] reeze dot xia at gmail dot com strip_tags will strip it even without the ending '>' if '<' followed by a non-space char. If we need to check whether is a closed tag it is a feature request to change it's behavior. it will break BC. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62032 -- Edit this bug report at https://bugs.php.net/bug.php?id=62032&edit=1
Bug #62032 [Opn]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 User updated by:iamcraigcampbell at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: So in that case I think strip_tags and filter_var are both broken. In this context: "It is true that 5<10" "It is true that 5 < 10" Neither of these are html tags so the string should not be touched regardless of if there is a space or not. Previous Comments: [2012-05-15 14:42:47] reeze dot xia at gmail dot com PS: the reason why strip_tags() didn't strip it is '<' is followed by a space char but not without ending '>', this is the key point. look deep into the source code, there difference is switch whether or not to trait '<' followed by a(or more) spaces a tag or not. [2012-05-15 14:36:26] reeze dot xia at gmail dot com strip_tags will strip it even without the ending '>' if '<' followed by a non-space char. If we need to check whether is a closed tag it is a feature request to change it's behavior. it will break BC. ------------ [2012-05-15 14:26:52] iamcraigcampbell at gmail dot com Well I can understand stripping it if there is a closing > somewhere, but if it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. I think strip_tags works as expected. [2012-05-15 14:24:14] reeze dot xia at gmail dot com Hi, I think it's a document problem. you could refer this commit: http://svn.php.net/viewvc?view=revision&revision=225196 strip_tags() didn't allow space after < so strip_tags didn't trait it as a invalid tag so it didn't get striped. filter_var allow space after < so, it striped everything after <. I think we could add an extra paramater to strip_tags() allow space after < and document it eg: string strip_tags(string str [, string allowable_tags = null [, bool allow_tag_spaces = false]]) [2012-05-14 17:19:48] iamcraigcampbell at gmail dot com Description: Noticed that for strings with < in them outside of html tags, filter_var will strip out all characters that come after the <. Test script: --- https://bugs.php.net/bug.php?id=62032&edit=1
Bug #62032 [Opn]: filter_var incorrectly strips characters from strings after "<"
Edit report at https://bugs.php.net/bug.php?id=62032&edit=1 ID: 62032 User updated by:iamcraigcampbell at gmail dot com Reported by:iamcraigcampbell at gmail dot com Summary:filter_var incorrectly strips characters from strings after "<" Status: Open Type: Bug Package:Filter related Operating System: Mac OS X PHP Version:5.4.3 Block user comment: N Private report: N New Comment: Well I can understand stripping it if there is a closing > somewhere, but if it is a < that is not followed by a matching > then it should be allowed in the string and not stripped. I think strip_tags works as expected. Previous Comments: [2012-05-15 14:24:14] reeze dot xia at gmail dot com Hi, I think it's a document problem. you could refer this commit: http://svn.php.net/viewvc?view=revision&revision=225196 strip_tags() didn't allow space after < so strip_tags didn't trait it as a invalid tag so it didn't get striped. filter_var allow space after < so, it striped everything after <. I think we could add an extra paramater to strip_tags() allow space after < and document it eg: string strip_tags(string str [, string allowable_tags = null [, bool allow_tag_spaces = false]]) ---------------- [2012-05-14 17:19:48] iamcraigcampbell at gmail dot com Description: Noticed that for strings with < in them outside of html tags, filter_var will strip out all characters that come after the <. Test script: --- https://bugs.php.net/bug.php?id=62032&edit=1
[PHP-BUG] Bug #62032 [NEW]: filter_var incorrectly strips characters from strings after "<"
From: Operating system: Mac OS X PHP version: 5.4.3 Package: Filter related Bug Type: Bug Bug description:filter_var incorrectly strips characters from strings after "<" Description: Noticed that for strings with < in them outside of html tags, filter_var will strip out all characters that come after the <. Test script: --- https://bugs.php.net/bug.php?id=62032&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62032&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62032&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62032&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62032&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62032&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62032&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62032&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62032&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62032&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62032&r=support Expected behavior: https://bugs.php.net/fix.php?id=62032&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62032&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62032&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62032&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62032&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62032&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62032&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62032&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62032&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62032&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62032&r=mysqlcfg
Bug #49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867&edit=1
ID: 49867
Comment by: iamcraigcampbell at gmail dot com
Reported by:nicolas dot lepage at yahoo dot fr
Summary:spl_autoload crashes when called in write function
of custom sessionSaveHandler
Status: No Feedback
Type: Bug
Package:SPL related
Operating System: *
PHP Version:5.3.0
Block user comment: N
New Comment:
Just experienced this issue after upgrading to PHP 5.3.3, APC 3.1.4 on
Debian
GNU/Linux 4.0.
When using the session handler from an instance of a class it would give
a fatal
error: Fatal error: Undefined class constant...
After switching to use static session handler methods there was no
longer a
fatal error, but it caused a segfault which was traced back to
spl_autoload_register().
Tried a bunch of stuff but was able to fix the issue by registering a
shutdown
function similar to this:
register_shutdown_function('shutdown');
function shutdown()
{
session_write_close();
}
Previous Comments:
[2010-06-12 23:39:43] zapparov at member dot fsf dot org
And one more interesting thing. This Fatal error is thrown (!) after all
operations were completed - so Im receiving exactly what I was expecting
to
receive but with Fatal Error and it's trace appended to it. o_O
[2010-06-12 23:34:44] zapparov at member dot fsf dot org
Unfortunately not for me.
Also, by some reason this problem occurs only on some requests. I'll try
to
prepare a simple test which will reproduce this issue soonly.
[2010-06-12 15:48:06] ras...@php.net
Doesn't calling session_write_close() completely solve this issue?
[2010-06-12 12:23:24] zapparov at member dot fsf dot org
Forgot to say - error occurs wonly when APC is enabled.
[2010-06-12 11:24:11] zapparov at member dot fsf dot org
Hello,
Have exactly the same problem with Zend Framework + Doctrine (they both
register
own autoloaders). So when APC is enabled - it reproduces same fatal
error. I'll
try to gather more information about what happens little bit later.
My PHP version is 5.3.2
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=49867
--
Edit this bug report at http://bugs.php.net/bug.php?id=49867&edit=1
