Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-654

Description for view or project does not escape text properly

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      When entering special html or language specific chars like the german ü, ä, ö
      these chars dont get escaped properly.

      Steps:
      1. Click the edit link for a view or a project
      2. Enter a text with a special char, like: ä, ö, ü, ü < ...
      3. Click save
      4. See the resulting webpage (it looks fine here)
      5. Click the edit link again
      6. Notice that > has become >, ü => ü, and ü becomes byte-trash
      (7. Save and notice the result page looks different than before the save even if
      you didnt change anything)

        Attachments

          Activity

          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Fixed in 1.121.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Fixed in 1.121.
          Hide
          zeisss zeisss added a comment -

          Hi,

          i just tested the new 1.121 build and the problem is only partially solved.
          The > issue is solved, but for special german chars like ü, ö, ä the problem
          still exists.

          The webpage is served with an UTF-8 encoding, maybe this helps.

          Show
          zeisss zeisss added a comment - Hi, i just tested the new 1.121 build and the problem is only partially solved. The > issue is solved, but for special german chars like ü, ö, ä the problem still exists. The webpage is served with an UTF-8 encoding, maybe this helps.
          Hide
          zeisss zeisss added a comment -

          Just changed the titel.

          Show
          zeisss zeisss added a comment - Just changed the titel.
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          I entered "ü ä" both from the config screen and from the project top page
          (by using the form that appears when I click "edit description".)

          The text is displayed as "ü ä" as expected, and when I try to edit this again,
          I'll be presented with "ü ä" as expected.

          So it all works correctly for me.

          Could you provide a detailed instruction to reproduce the problem. Please
          describe the page transition, each link you click, what you typed, etc.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - I entered "ü ä" both from the config screen and from the project top page (by using the form that appears when I click "edit description".) The text is displayed as "ü ä" as expected, and when I try to edit this again, I'll be presented with "ü ä" as expected. So it all works correctly for me. Could you provide a detailed instruction to reproduce the problem. Please describe the page transition, each link you click, what you typed, etc.
          Hide
          zeisss zeisss added a comment -

          Hi,

          I retestet this today with the 1.122 build, still no change. But i noted
          something on the encoding (see the end).

          My steps:
          1a. Open http://dev1.kuttig.com:8080/hudson/
          or 1b. Open http://dev1.kuttig.com/hudson/ (Tested both)
          2) Click "edit description" (http://dev1.kuttig.com:8080/hudson/editDescription)
          (Description gets replaced by the textarea)
          3) Enter a Text with "ü ä ö"
          4) Click "Submit" below the textarea
          5) See the reloaded page with the right text characters (ü ä ö)
          6) View page sourcecode (..<div>ü ä ö</div..) # Ok!

          7) Click "edit description" again
          (http://dev1.kuttig.com:8080/hudson/editDescription)
          8) Notice the textarea with "ü ä ö" # Not Ok

          Configuration details:
          1a) Hudson Winestone Standalone
          1b) Apache 2.2.3 with AJP Proxy to the standalone Hudson/Winstone process (same
          host)

          Client: Windows XP Prof. SP2 (Locale DE)
          Browser:

          • Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.5) Gecko/20070713
            Firefox/2.0.0.5
          • IE 6.0.2900
            Server: Redhat Linux

          Notes:
          When calling http://dev1.kuttig.com:8080/hudson/descriptionForm directly, in
          firefox the page is served as ISO-8859-1, but the frontpage at
          http://dev1.kuttig.com:8080/hudson/ is served as UTF-8. Maybe this results in
          the problem.

          Show
          zeisss zeisss added a comment - Hi, I retestet this today with the 1.122 build, still no change. But i noted something on the encoding (see the end). My steps: 1a. Open http://dev1.kuttig.com:8080/hudson/ or 1b. Open http://dev1.kuttig.com/hudson/ (Tested both) 2) Click "edit description" ( http://dev1.kuttig.com:8080/hudson/editDescription ) (Description gets replaced by the textarea) 3) Enter a Text with "ü ä ö" 4) Click "Submit" below the textarea 5) See the reloaded page with the right text characters (ü ä ö) 6) View page sourcecode (..<div>ü ä ö</div..) # Ok! 7) Click "edit description" again ( http://dev1.kuttig.com:8080/hudson/editDescription ) 8) Notice the textarea with "ü ä ö" # Not Ok Configuration details: 1a) Hudson Winestone Standalone 1b) Apache 2.2.3 with AJP Proxy to the standalone Hudson/Winstone process (same host) Client: Windows XP Prof. SP2 (Locale DE) Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 IE 6.0.2900 Server: Redhat Linux Notes: When calling http://dev1.kuttig.com:8080/hudson/descriptionForm directly, in firefox the page is served as ISO-8859-1, but the frontpage at http://dev1.kuttig.com:8080/hudson/ is served as UTF-8. Maybe this results in the problem.
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Aha! I was serving the "descriptionForm" page without specifying encoding, and
          according to the servlet spec, it then defaults to ISO-8859-1:

          Servlet Specification 2.3 (Proposed Final Draft 2), Section 5.4 (p. 44):

          'The default encoding of a response is "ISO-8859-1"
          if none has been specified by the servlet programmer.'

          (cited from
          http://mail-archives.apache.org/mod_mbox/tomcat-dev/200105.mbox/%3CPine.BSF.4.21.0105120906580.54618-100000@localhost%3E)

          (it's pretty stupid default if you ask me, but anyway...)

          Fixed in 1.125. Thanks for the details and analysis. It's almost like you fixed
          the problem by yourself!

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Aha! I was serving the "descriptionForm" page without specifying encoding, and according to the servlet spec, it then defaults to ISO-8859-1: Servlet Specification 2.3 (Proposed Final Draft 2), Section 5.4 (p. 44): 'The default encoding of a response is "ISO-8859-1" if none has been specified by the servlet programmer.' (cited from http://mail-archives.apache.org/mod_mbox/tomcat-dev/200105.mbox/%3CPine.BSF.4.21.0105120906580.54618-100000@localhost%3E ) (it's pretty stupid default if you ask me, but anyway...) Fixed in 1.125. Thanks for the details and analysis. It's almost like you fixed the problem by yourself!
          Hide
          zeisss zeisss added a comment -

          Thx. Tested again in 1.126 and works for me now.

          Show
          zeisss zeisss added a comment - Thx. Tested again in 1.126 and works for me now.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            zeisss zeisss
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: