[JAVASERVERFACES_SPEC_PUBLIC-237] ResponseWriter write escape arg Created: 25/Jan/07  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 237
Status Whiteboard:

EGTop5 effort_hard size_medium importance_medium draft


 Description   

Consideration: add optional escape boolean arg to ResponseWriter write methods
to control escaping.

See: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=464



 Comments   
Comment by rogerk [ 19/Mar/08 ]

Targeting for 2.0.

Comment by josefreire [ 20/Mar/08 ]

This issue is relevant when building a <f:selectOneMenu> and one of the
SelectItem has an itemValue that contains Unicode characters (like ç, á, ã).

On submit the validation fails due to the invalid characters.

This is a serious issue because many applications have decode tables that are
build by interface from outside systems, and one day you can wake up with a
broken application.

The workaround is to manually escape (using for example
StringEscapeUtils.escapeHtml) when building the SelectItems and unescaping
manually on receive.

The current behavior is always escaping itemValue, so this leads to a
double-escaping issue.

However, I believe this problem might be solved by changing the validation, and
not changing the ResponseWriter.

Looking at the HTML4 Spec I have found no hint that the existing restrictions on
Unicode characters should ever exist for itemValue since the "value" attribute
on the <OPTION> element is defined as CDATA, so Unicode characters should be
allowed.

I think the validation of the itemValue should be relaxed to allow more complex
values, like strings with Unicode characters.

Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 12/Sep/08 ]

effort_hard

Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 28/Jul/09 ]

Pushing to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 20/Jan/10 ]

Target 2.1

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Generated at Thu Dec 08 18:36:32 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.