Return-Path: 
 <commons-dev-return-21377-qmlist-jakarta-archive-commons-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@apache.org
Received: (qmail 2376 invoked from network); 19 Dec 2002 12:24:55 -0000
Received: from exchange.sun.com (HELO nagoya.betaversion.org) (192.18.33.10)
  by daedalus.apache.org with SMTP; 19 Dec 2002 12:24:55 -0000
Received: (qmail 2238 invoked by uid 97); 19 Dec 2002 12:26:04 -0000
Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org
Received: (qmail 2190 invoked by uid 97); 19 Dec 2002 12:26:03 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 2176 invoked by uid 50); 19 Dec 2002 12:26:02 -0000
Date: 19 Dec 2002 12:26:02 -0000
Message-ID: <20021219122602.2175.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 15526] New:  -
    Possible HttpClient codepage issue (ascii/ebcdic) on WebSphere z/OS
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15526>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15526

Possible HttpClient codepage issue (ascii/ebcdic) on WebSphere z/OS

           Summary: Possible HttpClient codepage issue (ascii/ebcdic) on
                    WebSphere z/OS
           Product: Commons
           Version: Nightly Builds
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: HttpClient
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: neal.johnston-ward@ubs.com


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
nuild on the 7th December.

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(HttpMethodBase.java:1791)
	at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1559)
	at
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.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 in some way. 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.

Could anybody adsvise on how to get this to work?

Regards,

Neal Johnston-Ward

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>