Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.6, 2.1, 2.1.0, 2.1.1, 2.1.2, 2.1.3
    • Fix Version/s: None
    • Component/s: ajax
    • Labels:
      None

      Description

      We have a general problem with the encoding situated somewhere between spec leak and implementation.
      Currently the encoding of an ajax request has a content-type: charset=utf-8
      While this is a valid header this might cause problems in non utf situations.
      The problem simply is once you have a page with another enconding you might run into the usual coding hell of savestating the input in the wrong encoding type.

      I investigated into the issue and found following out:

      https://issues.apache.org/jira/browse/MYFACES-3400

      a) Character encoding can easily be detected on the clientside without any additional server code

      b) We can change the request header accordingly, this needs patches on both implementations Mojarra and MyFaces, but they should be minimal.

      c) All browsers except Firefox pick that up properly, this is a big issue and a bugreport from my side has been filed on the Firefox side.
      https://bugzilla.mozilla.org/show_bug.cgi?id=703548

      d) The response then comes properly in the encoding given by the original page (response header is set properly)

      e) The encoding of the response xml is marked properly in the encoding of the request in Mojarra, Mojarra behaves properly there. MyFaces has an issue there by always sending the response content type in the partial response writer in UTF-8.
      A bug on the myfaces side has been filed on that one:
      https://issues.apache.org/jira/browse/MYFACES-3402

      So the question now is in which direction to go.
      Firefox has a problem, but does this really affect us. Since we nailed down the encoding incorrectly until now clientside to utf-8 and not to many users were affected, we probably can fix the issue without giving to many problems for firefox users. The downside is we would break backwards compatibility.

      If we make this behavior default off and add a config param one way or the other, we would be backwards
      compatible but would introduce yet another parameter.

      So the problem really comes down to the issue of:

      a) Do we autodetect and then set the encoding properly (would work
      without spec change probably but would mean that we break backwards compatibility minimally)

      b) Do we ignore it and stay where we are (in my opinion a no go)

      c) Do we introduce an artificial charset param which would mean a spec extension

        Activity

        Hide
        werpu12 added a comment - - edited

        Ok I did some deeper investigations into the issue. I guess we run into severe browser limitations there, best bet for now is to leave the encoding on UTF-8 even for non utf requests.

        So I probably would make the issue as invalid. The problem simply is limitations on the javascript side regarding non utf encoding. The JSF implementations seem to handle the non UTF case quite fine. By transcoding it properly into utf uri encoded strings and then decoding it back on the server side into its internal unicode structures.

        Please mark the issue as invalid and close it.

        Show
        werpu12 added a comment - - edited Ok I did some deeper investigations into the issue. I guess we run into severe browser limitations there, best bet for now is to leave the encoding on UTF-8 even for non utf requests. So I probably would make the issue as invalid. The problem simply is limitations on the javascript side regarding non utf encoding. The JSF implementations seem to handle the non UTF case quite fine. By transcoding it properly into utf uri encoded strings and then decoding it back on the server side into its internal unicode structures. Please mark the issue as invalid and close it.

          People

          • Assignee:
            rogerk
            Reporter:
            werpu12
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: