Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.2
    • Fix Version/s: None
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      237
    • Status Whiteboard:
      Hide

      EGTop5 effort_hard size_medium importance_medium draft

      Show
      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

        Activity

        Hide
        rogerk added a comment -

        Targeting for 2.0.

        Show
        rogerk added a comment - Targeting for 2.0.
        Hide
        josefreire added a comment -

        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.

        Show
        josefreire added a comment - 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.
        Hide
        rogerk added a comment -

        Status Whiteboard

        Show
        rogerk added a comment - Status Whiteboard
        Hide
        Ed Burns added a comment -

        effort_hard

        Show
        Ed Burns added a comment - effort_hard
        Hide
        Ed Burns added a comment -

        change target_milestone to 2.0

        Show
        Ed Burns added a comment - change target_milestone to 2.0
        Hide
        Ed Burns added a comment -

        Pushing to 2.1

        Show
        Ed Burns added a comment - Pushing to 2.1
        Hide
        Ed Burns added a comment -

        Prepare to delete api subcomponent

        Show
        Ed Burns added a comment - Prepare to delete api subcomponent
        Hide
        Ed Burns added a comment -

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

        Show
        Ed Burns added a comment - Move these to unscheduled because we need to target them correctly. 2.next isn't specific enough.
        Hide
        rogerk added a comment -

        Target 2.1

        Show
        rogerk added a comment - Target 2.1
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        Ed Burns added a comment -

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

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Manfred Riem added a comment -

        Setting priority to Minor

        Show
        Manfred Riem added a comment - Setting priority to Minor

          People

          • Assignee:
            Unassigned
            Reporter:
            rogerk
          • Votes:
            5 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: