php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #56938 Text enclosed by angle brackets vanishes from post variables
Submitted: 2006-04-06 12:08 UTC Modified: 2006-04-06 12:50 UTC
From: msaladna at apisnetworks dot com Assigned:
Status: Not a bug Package: filter (PECL)
PHP Version: 5.1.2 OS: Linux, RHEL3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: msaladna at apisnetworks dot com
New email:
PHP Version: OS:

 

 [2006-04-06 12:08 UTC] msaladna at apisnetworks dot com 
Description:
------------
This actually happens with PHP 5.1.2 and the filter extension built into PHP's interpreter directly.

On a post, all data that is enclosed by <>, e.g. HTML tags, even the PHP delimiters <?php ... ?> are removed from the variable.  Thus "<foo>" becomes "", "<?php ... some code ... ?>" becomes "", "<foo>bar</foo>" becomes "bar", and so on.

I have a workaround temporarily to remedy the problem.  Add an onSubmit event to the form tag and change all occurrences of < in the field to &amp;lt; which appears to fix it.

Hopefully this should be independent of the PHP build options and php.ini settings.  If not, let me know and I can include that information as well.

Reproduce code:
---------------
<?php
if (isset($_POST['code'])) { var_export($_POST); }
?>
<form method="post">
<textarea rows="40" cols="80" name="code" WRAP="OFF"></textarea>
<br />
<input type="submit" />
</form>

Enter something like, "<test>foo</test>" into the textarea

Expected result:
----------------
<test>foo</test>

Actual result:
--------------
foo

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-04-06 12:17 UTC] derick@php.net 
Sorry, but your problem does not imply a bug in PECL itself.  For a
list of more appropriate places to ask for help using PECL, please
visit http://pecl.php.net/support/ as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PECL.

This is not a bug, this is what filter is all about. I think you have set the default filter to strip_tags and then this behavior is perfectly normal. Check what phpinfo() says about the filter extention's settings.
 [2006-04-06 12:50 UTC] msaladna at apisnetworks dot com 
Sorry about the title, I just noticed Firefox.  Anyway though, I would expect for the default value to be unsafe_raw (or filter_off to disable filtering) keeping filter in a permissive state rather than strict state.  Per the default configuration, everything HTMLish tag will be stripped out of input variables, which can lead to problems with file managers/editors or for whatever reason, some application that uses <> extensively.  Consider it in a threaded environment where you can't dl() the extension to use it just once.  It would be loaded and thus go through the same filtering process for every page served up by the Web server.  This can lead to unexpected behavior with existing applications.

I would reconsider the default value for filter.default.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Apr 24 01:01:31 2024 UTC