MyFaces Core
  1. MyFaces Core
  2. MYFACES-3402

Partial Response Writer always returns an <?xml version='1.0' encoding='utf-8'?> ignoring the response encoding

    Details

    • Type: Bug Bug
    • Status: Patch Available
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.10, 2.1.4
    • Fix Version/s: None
    • Component/s: JSR-314
    • Labels:
      None

      Description

      While I was testing different ajax encodings I discovered that the Partial Response writer always returns the header listed on the headline of this issue. It ignores simply the original encoding.
      A blackbox test against Mojarra showed in that exact case the proper encoding not UTF-8 static.
      I guess the fix simply should be to make this part of the partial response writer more dynamic and to fetch
      the encoding in from the request header.

        Activity

        Hide
        Werner Punz added a comment -

        Additionally to that, if you pass special characters in an input field on a non utf request down the system, myfaces (also mojarra) mangles the result probably by assuming that only utf8 encoded stuff is passed down.

        Show
        Werner Punz added a comment - Additionally to that, if you pass special characters in an input field on a non utf request down the system, myfaces (also mojarra) mangles the result probably by assuming that only utf8 encoded stuff is passed down.
        Hide
        Dora Rajappan added a comment -

        ResourceHandlerImpl.java line 384 sets this
        httpServletResponse.setContentType(_getContentType(resource, facesContext.getExternalContext())); Hence this behaviour. Will you prefer httpServletResponse.setContentType(extContext.getRequestContentType()) to resolve this issue?

        Show
        Dora Rajappan added a comment - ResourceHandlerImpl.java line 384 sets this httpServletResponse.setContentType(_getContentType(resource, facesContext.getExternalContext())); Hence this behaviour. Will you prefer httpServletResponse.setContentType(extContext.getRequestContentType()) to resolve this issue?
        Hide
        Dora Rajappan added a comment -

        Set the content type of response from external context request.

        Show
        Dora Rajappan added a comment - Set the content type of response from external context request.
        Hide
        Leonardo Uribe added a comment -

        ResourceHandlerImpl is not the one responsible to deal with the encoding in an ajax request. Checking this part, it seems the encoding is set in javax.faces.context.PartialResponseWriter.startDocument() and it is always utf-8.

        It looks like that part is wrong. The javadoc says: "... write the start of a partial response. ...." so in that sense is right, but it should not write the xml preamble there. Instead, it should write the preamble in PartialViewContextImpl.processPartialRendering and take as content type the character encoding of the writer.

        Since this issue was not marked with component type JSR-314, it did not fell out of my radar. I'll check this one.

        Show
        Leonardo Uribe added a comment - ResourceHandlerImpl is not the one responsible to deal with the encoding in an ajax request. Checking this part, it seems the encoding is set in javax.faces.context.PartialResponseWriter.startDocument() and it is always utf-8. It looks like that part is wrong. The javadoc says: "... write the start of a partial response. ...." so in that sense is right, but it should not write the xml preamble there. Instead, it should write the preamble in PartialViewContextImpl.processPartialRendering and take as content type the character encoding of the writer. Since this issue was not marked with component type JSR-314, it did not fell out of my radar. I'll check this one.
        Hide
        Leonardo Uribe added a comment -

        This issue was clarified and fixed in 2.2.x branch. My personal opinion is it is better to let things as is in 2.1.x.

        Show
        Leonardo Uribe added a comment - This issue was clarified and fixed in 2.2.x branch. My personal opinion is it is better to let things as is in 2.1.x.

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Werner Punz
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development