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

go to bug id or search bugs for

Doc Bug #27361 strip_tags() doesn't fail on incomplete tag if there is non-html output before.
Submitted: 2004-02-23 05:18 UTC Modified: 2004-02-23 18:23 UTC
From: stu-php at better dot domain dot name Assigned: sean (profile)
Status: Closed Package: Documentation problem
PHP Version: 5.0.0b4 (beta4) OS: Windows Server 2003
Private report: No CVE-ID: None
View Developer Edit
 [2004-02-23 05:18 UTC] stu-php at better dot domain dot name 
Description:
------------
I have discovered that strip_tags() does not fail with an error if used on a string with an incomplete tag IF there is any non-tag text BEFORE the incomplete tag.

Reproduce code:
---------------
http://better.domain.name/php/strip.php
There's a link to the source on the page above showing the bug.

Expected result:
----------------
I would expect strip_tags() to fail if there is an incomplete html tag in the string passed to it, regardless of other input before, or after, the tag.

"This function tries to return a string with all HTML and PHP tags stripped from a given str. It errors on the side of caution in case of incomplete or bogus tags." - http://php.net/strip_tags

Actual result:
--------------
Only errors if there is no plain text before the broken tag.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-02-23 13:54 UTC] sniper@php.net 
Try outputting the actual result of the strip_tags() and you'll see that it works perfectly. (strip_tags() is not any validator...whatever the docs say)
 [2004-02-23 16:36 UTC] stu-php at better dot domain dot name 
This is NOT a bogus bug. Just because the MAIN functionality of the function is there does not mean that there is not a bug here.

The function behaves in an unexpected manner. That is a bug.

If the documentation contradicts the actual function then something needs to be fixed. Either the documentation or the function code.
 [2004-02-23 16:39 UTC] derick@php.net 
Explain in one line what the bug is then...I don't see it either.
 [2004-02-23 16:55 UTC] stu-php at better dot domain dot name 
The function returns an error if there is text in one place, but NOT if there is text in another set of places, or nowhere at all.
How is that NOT a bug?

If I were relying on this function to give me accurate error information in an if statement or something then I wouldn't want it erroring if and when it felt like it.

If it's supposed to strip html and error on invalid tags and then it goes ahead and fails to error because there is no text before the broken tag then there's a problem.

Consider: http://better.domain.name/php/strips.phps
The output has to be seen by viewing the source of http://better.domain.name/php/strips.php as it's completely erroneous output at the moment.

Is that the expected behaviour?
 [2004-02-23 16:57 UTC] stu-php at better dot domain dot name 
In one line, ok.

strip_tags() doesn't error in the way it says it should on the function documentation page.

That should be clear and concise enough.

Take a look at http://better.domain.name/php/ and tell me if the files there represent expected outcomes of strip_tags() usage.
 [2004-02-23 18:06 UTC] iliaa@php.net 
The fact that strip_tags() does not validate HTML and can 
strip excess data when encountering incomplete tags should 
be documented.
 [2004-02-23 18:23 UTC] sean@php.net 
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

removed "It errors on the side of caution in case of incomplete or bogus tags." and added a warning:

Because strip_tags does not actually validate the HTML, partial, or broken tags can result in unwanted results.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Jul 05 17:01:34 2025 UTC