Edit report at http://bugs.php.net/bug.php?id=54306&edit=1
ID: 54306
Comment by: carsten_sttgt at gmx dot de
Reported by: gingko at gingko dot homeip dot net
Summary: Parsing bug if a pattern looking like closing ASP
tag appears in comment
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Linux Debian 5 'Lenny'
PHP Version: 5.2.17
Block user comment: N
Private report: N
New Comment:
> Ok, so why ONLY in comments?
This also happens outside a comment.
| <?php
| if (true) {
| echo "foo";
| %>
| }
| ?>
Of course, in your case:
| echo "<font size=140%>Line 2</font><br>";
"%>" is inside a string and not parsed.
> Why only in LINE comments?
Because that's how the manual is describing comments:
| The "one-line" comment styles only comment to the end of the line
| or the current block of PHP code, whichever comes first.
(And a block is ending at "?>" or "%>".)
vs.:
| 'C' style comments end at the first */ encountered.
> Shouldn't the "?>" and "%>" tags be only able to close
> the corresponding "<?php"/"<?" and "<%" tags?
Maybe a idea for a feature request.
Conclusion:
The manual is clear how PHP is working in this situation. So it's the
fault of OCS Inventory (not thinking about a PHP installation with
enables ASP tags)
Previous Comments:
------------------------------------------------------------------------
[2011-03-18 13:25:08] gingko at gingko dot homeip dot net
Ok, so why ONLY in comments?
Why only in LINE comments?
And more, does it really make sense to allow closing PHP mode with an
ASP tag that is not even matching an opening "<%" ASP tag, but rather
only matching a "<?php" opening tag?
Shouldn't the "?>" and "%>" tags be only able to close the corresponding
"<?php"/"<?" and "<%" tags?
If you look better at my sample, you will see that the "%>" accidental
pattern is not completely unlikely to happen (for at least as long as
HTML will tolerate to have this kind of attribute's values not enclosed
in quotes).
I think that the time that I needed for finding that problem could be by
itself a good reason for changing something there.
------------------------------------------------------------------------
[2011-03-18 12:26:21] carsten_sttgt at gmx dot de
That's the normal behavior. See:
http://de.php.net/manual/en/language.basic-syntax.comments.php
"%>" is returning to HTML mode. But at this point the opened "{" from
the if is not closed, and it's not closed till the end of the file.
That's the error message.
------------------------------------------------------------------------
[2011-03-18 12:04:42] gingko at gingko dot homeip dot net
Description:
------------
A parsing error occurs if a pattern looking like a closing ASP tag
appears inside a line comment (beginning by '//'), in a PHP engine
having 'asp_tags = On' in the 'php.ini' file.
If I remove the "//" comment, I have a big "Line 2" visible, and there
is no bug.
If I use a "/* */" style comment instead, there is no bug.
If I put quotes around "140%" in the "size" attribute, there is no bug.
If I set the "asp_tags" options to "Off", or if I remove it, there is no
bug.
Removing the 'if' condition around the comment results in another kind
of problem (no error, but part of HTML code visible).
I found this because I was trying to install the latest version of OCS
Inventory (http://www.ocsinventory-ng.org/), and I didn't understand why
I got a white page and a PHP parse error after the first step of
installation: I have 'asp_tags = On' in 'php.ini', and there is
effectively a commented out '%>' pattern in their code.
Looks like a little to Bug #4879 (more than 10 years old).
Test script:
---------------
<html>
<head><title>Asp tag bug</title></head>
<body>
Line 1<br>
<?php
if (true) {
//echo "<font size=140%>Line 2</font><br>";
}
?>
Line 3<br>
</body>
</html>
Expected result:
----------------
Two text lines in browsers's Window :
"Line 1"
"Line 3"
Actual result:
--------------
A white page, and the following error in Apache log :
PHP Parse error: syntax error, unexpected $end in
/var/www/[...]/asp_tag_bug.php on line 13
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=54306&edit=1
