Tapestry
  1. Tapestry
  2. TAPESTRY-2501

Form input not correctly decoded in case of non-english charsets

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.13
    • Fix Version/s: 5.0.14
    • Component/s: None
    • Labels:
      None

      Description

      This problem occurs because major browsers don't conform to standards which says that client charset should be sent via "content-type" HTTP header to server.
      Everything is well described in this article:
      http://www.crazysquirrel.com/computing/general/form-encoding.jspx

      I guess this is closely related to submitted issue:
      https://issues.apache.org/jira/browse/TAPESTRY-915

      So, fix should be that
      HttpServletRequest.setEncodingCharset("UTF-8"); (I guess charset should be configurable somehow)
      is set in tapestry filter prior to anyone fetching any parameter value.

        Issue Links

          Activity

          Hide
          Howard M. Lewis Ship added a comment -

          TAPESTR-2543 now ensures that all incoming requests have their request encoding properly set as query parameters are extracted.

          Show
          Howard M. Lewis Ship added a comment - TAPESTR-2543 now ensures that all incoming requests have their request encoding properly set as query parameters are extracted.
          Hide
          Vjeran Marcinko added a comment -

          I don't know if this comment is needed, because I never loooked at T5 code to see where fix should be aplied, but it should affect both normal and multipart requests.

          Show
          Vjeran Marcinko added a comment - I don't know if this comment is needed, because I never loooked at T5 code to see where fix should be aplied, but it should affect both normal and multipart requests.
          Hide
          Howard M. Lewis Ship added a comment -

          That check occur when trying to restore persistent fields, potentially from stored request state (the t:state:client query parameter).

          Show
          Howard M. Lewis Ship added a comment - That check occur when trying to restore persistent fields, potentially from stored request state (the t:state:client query parameter).
          Hide
          Howard M. Lewis Ship added a comment -

          Looking at the code, I think I see how TAPESTRY-1605 is not quite fixed. The check for query parameters occur before there's a chance to set the request encoding.

          Show
          Howard M. Lewis Ship added a comment - Looking at the code, I think I see how TAPESTRY-1605 is not quite fixed. The check for query parameters occur before there's a chance to set the request encoding.
          Hide
          Howard M. Lewis Ship added a comment -

          The code and comments seem to indicate that TAPESTRY-1605 resolved this.

          Show
          Howard M. Lewis Ship added a comment - The code and comments seem to indicate that TAPESTRY-1605 resolved this.

            People

            • Assignee:
              Howard M. Lewis Ship
              Reporter:
              Vjeran Marcinko
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development