Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
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 :
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:
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.
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.