You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by bu...@apache.org on 2002/12/16 19:33:10 UTC
DO NOT REPLY [Bug 15407] New: -
APACHE XMLRPC HTTP header EBCDIC problem OS390 zOS
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=15407>.
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=15407
APACHE XMLRPC HTTP header EBCDIC problem OS390 zOS
Summary: APACHE XMLRPC HTTP header EBCDIC problem OS390 zOS
Product: XML-RPC
Version: unspecified
Platform: Other
URL: http://www.maaf.fr
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Source
AssignedTo: rpc-dev@xml.apache.org
ReportedBy: jean-yves.mulvet@maaf.fr
A java servlet, powered by IBM WEBSPHERE running in the Unix Services (USS) of
an IBM MVS OS390 or zOS platform, uses the XmlRpcClientLite class from the
org.apache.xmlrpc package.
The problem is that the client connection to the server fails.
It doesn't occur with IBM WEBSPHERE running on microsoft NT or WINDOWS 2000.
The IPTRACE obtained from the client side shows the following data in DUMP
format :
Offset Hexadecimal * EBCDIC | ASCII *
* translation | translation *
0000 D7D6E2E3 4061D9D7 C3F240C8 E3E3D761 *POST /RPC2 HTTP/|....�a....�....a*
0010 F14BF00D 15E4A285 9960C187 8595A37A *1.0..User-Agent:|.K.......�.....z*
0020 40C19781 83888540 E7D4D360 D9D7C340 * Apache XML-RPC |�......�...�...�*
0030 F14BF00D 15C896A2 A37A40F1 F04BF2F3 *1.0..Host: 10.23|.K.......z�..K..*
0040 F04BF9F2 4BF3F97A F8F0F00D 15C39695 *0.92.39:800..Con|.K..K..z........*
0050 A38595A3 60E3A897 857A40A3 85A7A361 *tent-Type: text/|....�....z�....a*
0060 A794930D 15C39695 A38595A3 60D38595 *xml..Content-Len|............�...*
0070 87A3887A 40F2F1F1 0D150D15 3C3F786D *gth: 211......._|...z�.......<?xm*
0080 6C207665 7273696F 6E3D2231 2E302220 *%......?>.......|l version="1.0" *
0090 656E636F 64696E67 3D224953 4F2D3838 *.>.?..>.....|...|encoding="ISO-88*
00A0 35392D31 223F3E3C 6D657468 6F644361 *........_...?../|59-1"?><methodCa*
00B0 6C6C3E3C 6D657468 6F644E61 6D653E43 *%%.._...?.+/_...|ll><methodName>C*
00C0 6F6E6E65 63745573 65723C2F 6D657468 *?>>........._...|onnectUser</meth*
00D0 6F644E61 6D653E3C 70617261 6D733E3C *?.+/_...././_...|odName><params><*
00E0 70617261 6D3E3C76 616C7565 3E61646D *././_.../%.../._|param><value>adm*
00F0 696E3C2F 76616C75 653E3C2F 70617261 *.>.../%.....././|in</value></para*
0100 6D3E3C70 6172616D 3E3C7661 6C75653E *_..././_.../%...|m><param><value>*
0110 3C626173 6536343E 59575274 61573471 *../........./...|<base64>YWRtaW4q*
0120 3C2F6261 73653634 3E3C2F76 616C7565 *.../......../%..|</base64></value*
0130 3E3C2F70 6172616D 3E3C2F70 6172616D *...././_...././_|></param></param*
0140 733E3C2F 6D657468 6F644361 6C6C3ED7 *...._...?../%%.P|s></methodCall>.*
We can see the HTTP header is coded in EBCDIC
This doesn�t comply with the RFC which says HTTP header must be US-ASCII coded.
So, the HTTP XMLRPC server is unable to understand the data received and close
the connection.
It seems the problem arises in the following section of apache code, because
native encoding of an MVS OS390 or zOS platform is EBCDIC :
http://xml.apache.org/xmlrpc/xref/org/apache/xmlrpc/XmlRpcClientLite
package org.apache.xmlrpc;
public InputStream sendRequest (byte[] request) throws IOException
{
output.write (("POST "+uri + " HTTP/1.0\r\n").getBytes());
output.write ( ("User-Agent: "+XmlRpc.version + "\r\n").getBytes());
output.write (("Host: "+host + "\r\n").getBytes());
if (XmlRpc.getKeepAlive())
output.write ("Connection: Keep-Alive\r\n".getBytes ());
output.write ("Content-Type: text/xml\r\n".getBytes ());
if (auth != null)
output.write ( ("Authorization: Basic "+auth + "\r\n").getBytes());
output.write ( ("Content-Length: "+request.length).getBytes ());
output.write ("\r\n\r\n".getBytes());
output.write (request);
output.flush ();
.......
So, we tried the following modified code :
public InputStream sendRequest (byte[] request) throws IOException
{
output.write (("POST "+uri + " HTTP/1.0\r\n").getBytes(XmlRpc.encoding));
output.write ( ("User-Agent: "+XmlRpc.version + "\r\n").getBytes
(XmlRpc.encoding));
output.write (("Host: "+host + "\r\n").getBytes(XmlRpc.encoding));
if (XmlRpc.getKeepAlive())
output.write ("Connection: Keep-Alive\r\n".getBytes (XmlRpc.encoding));
output.write ("Content-Type: text/xml\r\n".getBytes (XmlRpc.encoding));
if (auth != null)
output.write ( ("Authorization: Basic "+auth + "\r\n").getBytes
(XmlRpc.encoding));
output.write ( ("Content-Length: "+request.length).getBytes
(XmlRpc.encoding));
output.write ("\r\n\r\n".getBytes(XmlRpc.encoding));
output.write (request);
output.flush ();
.......
The IP trace made after the modification shows that the problem is bypassed :
HTTP header is now US-ASCII coded.
Offset Hexadecimal * EBCDIC | ASCII *
* translation | translation *
0000 504F5354 202F5250 43322048 5454502F *&|.....&......&.|POST /RPC2 HTTP/*
0010 312E300D 0A557365 722D4167 656E743A *.............>..|1.0..User-Agent:*
0020 20417061 63686520 584D4C2D 52504320 *.../.....(<..&..| Apache XML-RPC *
0030 312E300D 0A486F73 743A2031 302E3233 *......?.........|1.0..Host: 10.23*
0040 302E3932 2E33393A 3830300D 0A436F6E *..............?>|0.92.39:800..Con*
0050 74656E74 2D547970 653A2074 6578742F *..>.............|tent-Type: text/*
0060 786D6C0D 0A436F6E 74656E74 2D4C656E *._%...?>..>..<.>|xml..Content-Len*
0070 6774683A 20323131 0D0A0D0A 3C3F786D *..............._|gth: 211....<?xm*
0080 6C207665 7273696F 6E3D2231 2E302220 *%......?>.......|l version="1.0" *
0090 656E636F 64696E67 3D224953 4F2D3838 *.>.?..>.....|...|encoding="ISO-88*
00A0 35392D31 223F3E3C 6D657468 6F644361 *........_...?../|59-1"?><methodCa*
00B0 6C6C3E3C 6D657468 6F644E61 6D653E43 *%%.._...?.+/_...|ll><methodName>C*
00C0 6F6E6E65 63745573 65723C2F 6D657468 *?>>........._...|onnectUser</meth*
00D0 6F644E61 6D653E3C 70617261 6D733E3C *?.+/_...././_...|odName><params><*
00E0 70617261 6D3E3C76 616C7565 3E61646D *././_.../%.../._|param><value>adm*
00F0 696E3C2F 76616C75 653E3C2F 70617261 *.>.../%.....././|in</value></para*
0100 6D3E3C70 6172616D 3E3C7661 6C75653E *_..././_.../%...|m><param><value>*
0110 3C626173 6536343E DFEFEAC8 2FEF94C9 *../........H..mI|<base64>..../...*
0120 3C2F6261 73653634 3E3C2F76 616C7565 *.../......../%..|</base64></value*
0130 3E3C2F70 6172616D 3E3C2F70 6172616D *...././_...././_|></param></param*
0140 733E3C2F 6D657468 6F644361 6C6C3E *...._...?../%%. |s></methodCall> *
What is the correct way to fix this problem ?
Thanks and regards.
bruno.puchault@maaf.fr
philippe.lacassie@maaf.fr
jean.yves@maaf.fr