hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: Possible code page problem
Date Wed, 08 Jan 2003 08:58:04 GMT
Just a few thoughts from the top of my head

1) I seriously doubt that in this particular instance the problem lies with HttpClient. My
assumption may be wrong, but to my knowledge problems related to character encoding should
not result in a completely garbled output. Non-ascii characters (non-latin characters, German
umlauts, etc) may be improperly converted, but not ascii characters. In any case it should
not render response header unparseable

2) HttpClient does apply appropriate character encoding PROVIDED it has been specified. Make
sure your Content-Type header also specifies charset used. (Only applies to PUT and POST methods)

Content-Type: text/xml; charset=UTF-8

3) I have extensive experience with Websphere 4.0.x on Solaris and AIX. If you are using Websphere
version 4, make sure latest OS patches and upgrade AT LEAST to version 4.0.2. The version
of WebSphere shipped on original CDs (usually 4.0.1) is buggy beyond any reasonable measure

4) On all Unices it is important to set environmental variable LANG in order to have proper
charset conversion under WebSphere. I can't tell if this applies to z/OS.

Keep us posted

Cheers

Oleg


-----Original Message-----
From: neal.johnston-ward@ubs.com [mailto:neal.johnston-ward@ubs.com]
Sent: Wednesday, January 08, 2003 09:12
To: commons-httpclient-dev@jakarta.apache.org
Subject: Possible code page problem


Hi,

I am working with Cactus 1.4.1 on WebSphere NT and also WebSphere z/OS
(mainframe). The problem seems to be with HTTPClient. I have tried with
the nightly build on the 7th December and the problem is still there.

I am trying to get basic cactus servlet tests working on WebSphere z/OS.
Everything works fine through WebSphere NT, however, when the same
application is deployed to WebSphere z/OS then we get the following
error:

<?xml version="1.0" encoding="UTF-8" ?><?xml-stylesheet type="text/xsl"
href="junit-noframes.xsl"?><testsuites><testsuite
name="TestCactusServlet" tests="1" failures="0" errors="1"
time="10.184"><testcase name="testNeal" time="10.182"><error
message="Error in parsing the status  line from the response: unable to
find line starting with &quot;HTTP/&quot;"
type="org.apache.commons.httpclient.HttpRecoverableException">org.apache
.commons.httpclient.HttpRecoverableException:
Error in parsing the status  line from the response: unable to find line
starting with &quot;HTTP/&quot;
      at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBa
se.java:1791)
      at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
.java:1559)
      at
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa
se.java:2219)
      ... etc ...

I have verified that the Application Server on WebSphere z/OS is working
fine. I set the logging on the cactus to DEBUG and noticed that the data
that the HTTPClient is retrieving from the connection is scrambled. For
example:

16:06:20,213 [WebSphere t=009d7920] DEBUG ent.HttpClientConnectionHelper
-
>getCookieString = [null] 
16:06:20,317 [WebSphere t=009d7920] DEBUG httpclient.wire               
- >> "ÇÅã@aã?¢£Ã?? etc...

On WebSphere NT the data at this point looks OK.

What springs to mind is maybe ascii/ebcdic conversion problem. z/OS uses
unicode  for java, as it should. However, the HTTPClient creates it own
socket connection to the app server and therefore it is connecting to
non java code. In such a situation codepage conversion is necessary.

I have raised a problem on this through Bugzilla (* 15526) but so far no
response. Could anybody adsvise me on this error? I am prepared to help
out coding and testing but I would like some thoughts on this from the
developers of HTTPclient before I go steaming in there.

Regards,

Neal 



Mime
View raw message