Bug 7670

Summary: <fmt:requestEncoding> with no value attribute specified doesn't set the character encoding properly based on the spec.
Product: Taglibs Reporter: Ryan Lubke <Ryan.Lubke>
Component: Standard TaglibAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: major    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Ryan Lubke 2002-04-01 20:00:40 UTC
Section 8.8, page 8-86 states that if the <fmt:requestEncoding> action has no
value attribute specified, that the encoding to be used is determined using the
following algorithm:
   - If the Content-Type request header is defined, use the value defined
     by the header.
   - If no Content-Type header, use the value associated with the scoped variable
     javax.servlet.jsp.jstl.fmt.request.charset.
   - If none of the above conditions are satisfied, use the default of ISO-8859-1.

There are two problems, both located in
org.apache.taglibs.standard.tag.common.fmt.RequestEncodingSupport:

  1.  The character encoding as specified by a Content-Type header is 
      never considered.

  2.  If the javax.servlet.jsp.jstl.fmt.request.charset attribute is not
      set, the default encoding is not applied.

Below is a possible fix for the issue:

*******************************************************************************
Index: RequestEncodingSupport.java
===================================================================
RCS file:
/home/cvs/jakarta-taglibs/standard/src/org/apache/taglibs/standard/tag/common/fmt/RequestEncodingSupport.java,v
retrieving revision 1.3
diff -u -r1.3 RequestEncodingSupport.java
--- RequestEncodingSupport.java 1 Feb 2002 01:16:47 -0000   1.3
+++ RequestEncodingSupport.java 1 Apr 2002 18:47:45 -0000
@@ -77,6 +77,8 @@
     static final String REQUEST_CHAR_SET =
    "javax.servlet.jsp.jstl.fmt.request.charset";

+    static final String DEFAULT_ENCODING = "ISO-8859-1";
+

     //*********************************************************************
     // Protected state
@@ -101,24 +103,35 @@
     // Tag logic

     public int doEndTag() throws JspException {
-   if ((value == null)
-         && (pageContext.getRequest().getCharacterEncoding() == null)) {
-       /*
-        * no charset specified in tag or defined in request Content-Type
-        * header
-        */
-       value = (String) pageContext.findAttribute(REQUEST_CHAR_SET);
-   }

-   if (value != null) {
+        String reqEnc = pageContext.getRequest().getCharacterEncoding();
+
+        if (value == null && reqEnc != null) {
+            /*
+             * no charset specified in tag, but it was specified in
+             * the request's Content-Type header
+             */
+            value = reqEnc;
+        } else if (value == null && reqEnc == null) {
+           /*
+            * no charset specified in tag or defined in request Content-Type
+            * header
+            */
+           value = (String) pageContext.findAttribute(REQUEST_CHAR_SET);
+            if (value == null) {
+                
+                // use the default encoding for the request
+                value = DEFAULT_ENCODING;
+            }
+       }
+
        try {
-       pageContext.getRequest().setCharacterEncoding(value);
+           pageContext.getRequest().setCharacterEncoding(value);
        } catch (UnsupportedEncodingException uee) {
-       throw new JspTagException(uee.getMessage());
+           throw new JspTagException(uee.getMessage());
        }
-   }

-   return EVAL_PAGE;
+       return EVAL_PAGE;
     }

     // Releases any resources we may have (or inherit)
**********************************************************
Comment 1 Jan Luehe 2002-04-01 20:23:33 UTC
Fixed.
Comment 2 Jan Luehe 2002-04-02 23:00:32 UTC
Agree with problem 2 (default encoding not applied) in the bug description
section, but not problem 1 ("The character encoding as specified by a
Content-Type header is never considered.").

In the case where the request already specifies a char encoding, we should not
have to do anything, since retrieving the request encoding using

  pageContext.getRequest().getCharacterEncoding()

and then setting it using

  pageContext.getRequest().setCharacterEncoding(value);

should be redundant.

Fixed problem 1.