Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 6.1.4
    • Fix Version/s: 6.1.5rc0
    • Component/s: None
    • Labels:
      None
    • Environment:
      zOS
    • Number of attachments :
      0

      Description

      From jason randall:

      I'm making a call to getRequestURL() on the Request object from a servlet
      running on Jetty 6.1.1 on a z/OS machine running with uss using the default file
      encoding which is Cp1047. This call returns almost everything correctly,
      including the scheme, port and uri. However, the host name is encoded
      improperly. So for example instead of getting the following:

      http://mvsbuss:9080/redirect

      I get:

      http://_˚:9080/redirect

      It looks like the getServerName in org.mortbay.jetty.Request is assuming the
      value in the Host HTTP Header is using the mainframe's default system encoding.
      AbstractBuffer.toString() does not provide a character encoding option other
      than the system's character encoding. Whereas when determining the
      Request.getResultURI() a UTF-8 encoding scheme is used no matter what the
      system's encoding is set.

      I do have a workaround for this issue by re-encoding the server name using UTF-8
      however I get a similar issue when the DefaultServlet (makes a call to
      passConditionalHeaders) attempts to parse the value in the If-Modified-Since
      header as a date but the string was encoding using the system default and a
      java.lang.IllegalArgumentException: Cannot convert date is thrown.

      I would rather not set the file.encoding system property to UTF-8 because then
      my log files will not be readable on the z/OS machine. This was working
      properly in Jetty 4.1 without having to set the file.encoding property.

      Any insight into a possible work aroud for this would be appreciated.

        Activity

        Hide
        Greg Wilkins added a comment -

        Jason,

        I have checked in what should be at least a partial fix for this issue.
        But, a larger audit/test would be needed to confirm all functions operate
        correctly.

        Show
        Greg Wilkins added a comment - Jason, I have checked in what should be at least a partial fix for this issue. But, a larger audit/test would be needed to confirm all functions operate correctly.
        Hide
        Greg Wilkins added a comment -

        If you can confirm this works for you, I'll mark this resolved.

        Show
        Greg Wilkins added a comment - If you can confirm this works for you, I'll mark this resolved.
        Hide
        Jason Randall added a comment -

        Greg,

        The fix looks good. When do think it will make into an official release? Will it be in 6.1.5?

        Show
        Jason Randall added a comment - Greg, The fix looks good. When do think it will make into an official release? Will it be in 6.1.5?
        Hide
        Greg Wilkins added a comment -

        yes it will be in 6.1.5, which should be next week.

        Show
        Greg Wilkins added a comment - yes it will be in 6.1.5, which should be next week.

          People

          • Assignee:
            Unassigned
            Reporter:
            Greg Wilkins
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: