glassfish
  1. glassfish
  2. GLASSFISH-18453

multipart/form-data problem with myfaces extension filter

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Works as designed
    • Affects Version/s: 3.1.2_b23
    • Fix Version/s: None
    • Component/s: web_container
    • Labels:
      None
    • Environment:

      glassfish 3.1.2 build 23, jre 7, ubuntu linux

    • Status Whiteboard:
      Hide

      myfaces ExtensionsFilter doesn't work with glassfish 3.1.2. A h:form with multipart/form-data with page encoding utf-8 sets h:inputText with wrong charset. As a result the database is corrupted with unreadable chars and the page is reloaded with strange characters. Also no file is upload by the managed bean. Maybe related with issue GLASSFISH-16740?

      The same application works with glassfish 3.1, 3.0.1

      Show
      myfaces ExtensionsFilter doesn't work with glassfish 3.1.2. A h:form with multipart/form-data with page encoding utf-8 sets h:inputText with wrong charset. As a result the database is corrupted with unreadable chars and the page is reloaded with strange characters. Also no file is upload by the managed bean. Maybe related with issue GLASSFISH-16740 ? The same application works with glassfish 3.1, 3.0.1

      Description

      myfaces ExtensionsFilter doesn't work with glassfish 3.1.2. A h:form with multipart/form-data with page encoding utf-8 sets h:inputText with wrong charset. As a result the database is corrupted with unreadable chars and the page is reloaded with strange characters. Also no file is upload by the managed bean. Maybe related with issue GLASSFISH-16740?

      The same application works with glassfish 3.1, 3.0.1

        Activity

        Hide
        kchung added a comment -

        Are you doing the file upload with servlet 3.0 Request.getPart() or on your own. If it is the latter, you may want to see if the patch in http://java.net/jira/browse/GLASSFISH-18444 fixes your problem.

        Otherwise, you'll need to come up with a simple test case for me to work on.

        Show
        kchung added a comment - Are you doing the file upload with servlet 3.0 Request.getPart() or on your own. If it is the latter, you may want to see if the patch in http://java.net/jira/browse/GLASSFISH-18444 fixes your problem. Otherwise, you'll need to come up with a simple test case for me to work on.
        Hide
        dani_drio added a comment -

        Related to the charset problem I attach a simple NetBeans project (TestCharset.zip) with a web app. Only one jsp exists with a simple form. To test:

        • Run the project
        • In the jsp form input type 'ó' and click the 'Send' button.
        • The input now shows 'ó' instead of 'ó'

        Now, remove the enctype="multipart/form-data" and the forms works ok.

        I tested the patch web-core.jar you suggested but not solve the problem.

        Thanks in advance.

        Show
        dani_drio added a comment - Related to the charset problem I attach a simple NetBeans project (TestCharset.zip) with a web app. Only one jsp exists with a simple form. To test: Run the project In the jsp form input type 'ó' and click the 'Send' button. The input now shows 'ó' instead of 'ó' Now, remove the enctype="multipart/form-data" and the forms works ok. I tested the patch web-core.jar you suggested but not solve the problem. Thanks in advance.
        Hide
        kchung added a comment -

        The problem has nothing to do with multipart processing in the container. In fact, the following JSP page show the same symptom.

        <%@page contentType="text/html" pageEncoding="UTF-8"%>
        <html>
        <body>

        <form method="post" action="form.jsp">
        <input type="text" name="name" value="$

        {param.name}

        " size="12"/>
        <input type="submit"/>
        </form>

        </body>
        </html>

        The problem is with the character encoding of the POST data. Depending on the browser, the request encoding may not be specified correctly.

        If I add the following line after the page directive, it works as expected.

        <% request.setCharacterEncoding("UTF8"); %>

        Show
        kchung added a comment - The problem has nothing to do with multipart processing in the container. In fact, the following JSP page show the same symptom. <%@page contentType="text/html" pageEncoding="UTF-8"%> <html> <body> <form method="post" action="form.jsp"> <input type="text" name="name" value="$ {param.name} " size="12"/> <input type="submit"/> </form> </body> </html> The problem is with the character encoding of the POST data. Depending on the browser, the request encoding may not be specified correctly. If I add the following line after the page directive, it works as expected. <% request.setCharacterEncoding("UTF8"); %>
        Hide
        dani_drio added a comment -

        In my opinion the problem is with the web engine (or something related to JSF). The browser should receive the same headers related to encoding in both cases. If you try this JSF it will not work:

        <%@page contentType="text/html" pageEncoding="UTF-8"%>

        <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
        <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

        <% request.setCharacterEncoding("UTF-8"); %>

        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">

        <f:view>
        <html>
        <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
        </head>
        <body>
        <h:form id="mainForm" enctype="multipart/form-data">
        <div>
        <h:inputText size="12"/>
        </div>
        <h:commandButton value="Send"/>
        </h:form>
        </body>
        </html>
        <h:messages/>
        </f:view>

        This JSF has the request.setCharacterEncoding("UTF-8") as you suggested and works properly with older glassfish versions (with o without multipart) and in glassfish 3.1.2 when the multipart is not present. So, has no sense to get different behavior. It makes impossible to work our CMS with multi-language web applications.

        Thanks.

        Show
        dani_drio added a comment - In my opinion the problem is with the web engine (or something related to JSF). The browser should receive the same headers related to encoding in both cases. If you try this JSF it will not work: <%@page contentType="text/html" pageEncoding="UTF-8"%> <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%> <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%> <% request.setCharacterEncoding("UTF-8"); %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <f:view> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> </head> <body> <h:form id="mainForm" enctype="multipart/form-data"> <div> <h:inputText size="12"/> </div> <h:commandButton value="Send"/> </h:form> </body> </html> <h:messages/> </f:view> This JSF has the request.setCharacterEncoding("UTF-8") as you suggested and works properly with older glassfish versions (with o without multipart) and in glassfish 3.1.2 when the multipart is not present. So, has no sense to get different behavior. It makes impossible to work our CMS with multi-language web applications. Thanks.
        Hide
        kchung added a comment -

        In your JSF test, what is the easiest way to display the text from h:inputText. Sorry I don't know JSF too much.

        The addition of enctype="multipart/form-data" to h:form seems to do something strange. If I add an action to H:commandButton, it wouldn't even go there!

        Show
        kchung added a comment - In your JSF test, what is the easiest way to display the text from h:inputText. Sorry I don't know JSF too much. The addition of enctype="multipart/form-data" to h:form seems to do something strange. If I add an action to H:commandButton, it wouldn't even go there!
        Hide
        dani_drio added a comment -

        Only needs to press the "Send" button. Because no binding to a managed bean exists JSF will restore the value automatically in the input.

        I check the "action" for commandButton and works fine. So, in principle I discard a problem here.

        I check the HTTP headers the browser receives with firebug and in both cases, with and without "multipart/form-data", seems to be ok.

        It appears the problem is in the process of extracting the parameter values from the multi-part response the server receives. I think the server is assuming incorrectly the response is ISO-8859-1.

        Show
        dani_drio added a comment - Only needs to press the "Send" button. Because no binding to a managed bean exists JSF will restore the value automatically in the input. I check the "action" for commandButton and works fine. So, in principle I discard a problem here. I check the HTTP headers the browser receives with firebug and in both cases, with and without "multipart/form-data", seems to be ok. It appears the problem is in the process of extracting the parameter values from the multi-part response the server receives. I think the server is assuming incorrectly the response is ISO-8859-1.
        Hide
        kchung added a comment -

        Hmm.. I only got a blank in the input after hitting "Send" button. Running glassfish trunk with Internet Explorer 8.

        If the problem is just using the wrong char encoding when extracting the request parameters, then inserting a java scriptlet to set the request char encoding should work. The thing that I am not sure of is when the code is executed. With JSF, there may be some timing issue.

        It'd be great if you can come up with a test without JSF.

        Show
        kchung added a comment - Hmm.. I only got a blank in the input after hitting "Send" button. Running glassfish trunk with Internet Explorer 8. If the problem is just using the wrong char encoding when extracting the request parameters, then inserting a java scriptlet to set the request char encoding should work. The thing that I am not sure of is when the code is executed. With JSF, there may be some timing issue. It'd be great if you can come up with a test without JSF.
        Hide
        dani_drio added a comment -

        I see some light ... I made a test without JSF and works as you says in previous message: it's needed the "request.setCharacterEncoding("UTF-8");" to work in both cases with and without multipart. That is not a surprise, and in the past (when no JSF exists) we forced this in a web filter.

        When JSF is used I think mojarra do some "magic" process to set the properly enconding based in the last request or something similar. Googling I see this value is saved in the session attribute "javax.faces.request.charset". If you print the session attributes in the jsp:

        <%
        for (Enumeration e = request.getSession().getAttributeNames(); e.hasMoreElements(); )

        { String att = (String)e.nextElement(); out.println(att + ": " + request.getAttribute(att) + "<br/>"); }

        %>

        You will see this.

        So, mojarra seems to works different that in previous versions, and the worse is the behavior is different with or wihout multipart.

        Please, can you change the state of this bug to open?

        Tanhks in advance.

        Show
        dani_drio added a comment - I see some light ... I made a test without JSF and works as you says in previous message: it's needed the "request.setCharacterEncoding("UTF-8");" to work in both cases with and without multipart. That is not a surprise, and in the past (when no JSF exists) we forced this in a web filter. When JSF is used I think mojarra do some "magic" process to set the properly enconding based in the last request or something similar. Googling I see this value is saved in the session attribute "javax.faces.request.charset". If you print the session attributes in the jsp: <% for (Enumeration e = request.getSession().getAttributeNames(); e.hasMoreElements(); ) { String att = (String)e.nextElement(); out.println(att + ": " + request.getAttribute(att) + "<br/>"); } %> You will see this. So, mojarra seems to works different that in previous versions, and the worse is the behavior is different with or wihout multipart. Please, can you change the state of this bug to open? Tanhks in advance.
        Hide
        kchung added a comment -

        reopen and assign to Ed Burns to look into this further.

        Show
        kchung added a comment - reopen and assign to Ed Burns to look into this further.
        Hide
        kchung added a comment -

        I've fixed a related issue, http://java.net/jira/browse/GLASSFISH-18453. Can you verify if that also fixes this issue?

        Show
        kchung added a comment - I've fixed a related issue, http://java.net/jira/browse/GLASSFISH-18453 . Can you verify if that also fixes this issue?
        Hide
        kchung added a comment -
        Show
        kchung added a comment - Oops. I meant http://java.net/jira/browse/GLASSFISH-18516
        Hide
        dani_drio added a comment -

        No, I try the last 4.0 (build 27) and has the same problem.

        Show
        dani_drio added a comment - No, I try the last 4.0 (build 27) and has the same problem.
        Hide
        kchung added a comment -

        Build 27 does not include the fix. Try b30.

        Show
        kchung added a comment - Build 27 does not include the fix. Try b30.
        Hide
        dani_drio added a comment -

        No, b30 does not solve the problem.

        Show
        dani_drio added a comment - No, b30 does not solve the problem.
        Hide
        dani_drio added a comment -

        Causally I found a solution. The problem seems to appear when this combination occurs:

        • the form is multipart
        • the page has a page directive declaring the encoding: <%@page pageEncoding="UTF-8"%>

        The solution is:

        • declare in descriptor glassfish-web.xml the param: <parameter-encoding default-charset="UTF-8"/>
        • remove the page directive in all the jsf pages.

        This solution also removes from the log the typical warning:

        "Unable to set request character encoding to UTF-8 from context xxxx, because request parameters have already been read, or ServletRequest.getReader() has already been called"

        regards.

        Show
        dani_drio added a comment - Causally I found a solution. The problem seems to appear when this combination occurs: the form is multipart the page has a page directive declaring the encoding: <%@page pageEncoding="UTF-8"%> The solution is: declare in descriptor glassfish-web.xml the param: <parameter-encoding default-charset="UTF-8"/> remove the page directive in all the jsf pages. This solution also removes from the log the typical warning: "Unable to set request character encoding to UTF-8 from context xxxx, because request parameters have already been read, or ServletRequest.getReader() has already been called" regards.

          People

          • Assignee:
            Ed Burns
            Reporter:
            dani_drio
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: