html:option tag does not apply any filtering to escape HTML-sensitive characters

• Key: STR-2932
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: John R. Fallows
• Component/s: Tag Libraries
• Affects Version/s: 1.3.5
• Fix Version/s: 1.3.6

Description

The filter attribute is available for html:options and html:optionsCollection, but is missing for html:option.

The filter attribute on html:option would behave in a manner consistent with the html:options and html:optionsCollection tags, causing HTML-sensitive characters, such as ampersand, to be escaped in the HTML output.

This issue is marked as a bug because it is not currently possible to post back the selected option value when it contains HTML-sensitive characters -- either the html:option value is not properly escaped or, if the application developer manually escapes the option value, then the postback value is the unescaped value.

Comments

[John R. Fallows]

Please review the attached patch which implements a resolution to this issue.

[John R. Fallows]

This patch adds support for filter attribute in Struts EL html:option tag.

[John R. Fallows]

There's a design choice to be made here, consistency with 1.3.5 API for filter=true default vs. consistency with 1.3.5 behavior for <html:option value="..." /> when value contains special chars like ampersand.

Since i don't know the policy, i chose not to break compatibility, so filtered=false is the default. But, I'd be happy to re-work the patch to make filtered=true the default, if the Struts community decides this is the way to go.

Perhaps the change in behavior is not such a big deal, since it will only affect option values that contain special characters. Those option values cannot be properly sent back to the server anyway, since they will be in their unescaped form during postback.

[James Mitchell]

As was indicated in the dev list discussion, this (newly added) filter attribute for OptionTag has the opposite default behaviour when compared to the same thing in OptionsTag. Not sure whether this needs a point relase or higher before the behaviour can be matched up between the two.