Maybe this only happens for file upload, though.

Well, and textarea input, too, presumably. Maybe it's a bad idea to have different validation for different input methods anyway.

Note that <?php ... ?> can appear anywhere, including attribute values and in <script>.

(In reply to comment #2)
> Note that <?php ... ?> can appear anywhere, including attribute values and in
> <script>.

I think that from the point of view of the v.nu code, checking for this stuff in attribute values is a pretty different kind of case from checking for it in element content. I think it'd be possible to handle the attribute-value case in the Java assertions-checking code (in syntax/non-schema), without touching the parser code.

btw, does PHP and such allow stuff like <foo <?php ... ?> bar=baz>

(In reply to comment #3)
> I think that from the point of view of the v.nu code, checking for this stuff
> in attribute values is a pretty different kind of case from checking for it in
> element content. I think it'd be possible to handle the attribute-value case in
> the Java assertions-checking code (in syntax/non-schema), without touching the
> parser code.

To be clear, by mean "handling" it for the attribute-value case, I mean just catching it and reporting it with an error message saying, "looks like you have some PHP stuff in this attribute value, you should validate your generated HTML instead".

I guess it might be worthwhile to add some code to do that reporting.

But it seems to me likely that many (or most) people don't actually want to be advised to validate the generated HTML instead. I'd guess that what they really want instead is to be able to check documents containing this stuff without it getting reported to them as an error -- e.g., while they are actually editing the source for a document (using v.nu through the some kind of integration of the v.nu REST API into their editing app).

For people who want that, I don't think it's likely we are going to be able to make them happy. At least not for the attribute case. Because as far as I can see, not reporting it as an error for the attribute-value case would require making changes to all the datatype-checking code to allow "<?" and whatever through even though it doesn't match the allowed microsyntax/datatype for the attribute.

> btw, does PHP and such allow stuff like <foo <?php ... ?> bar=baz>

Yes. The PHP processor ignores all HTML markup.

Perhaps it should just be on a layer before tokenization, looking for the character sequence "<?php" (and "<%" for ASP or whatever) and emits a single message with the advice.