[ http://issues.apache.org/jira/browse/XMLRPC-22?page=all ]
Jochen Wiedmann closed XMLRPC-22:
---------------------------------
Resolution: Won't Fix
Assign To: (was: rpc-dev mailing list)
The issue has seen no activity in more than three years. Consequently, I am now
closing it. Please reopen, if required.
> APACHE XMLRPC HTTP header EBCDIC problem OS390 zOS
> --------------------------------------------------
>
> Key: XMLRPC-22
> URL: http://issues.apache.org/jira/browse/XMLRPC-22
> Project: XML-RPC
> Type: Bug
> Components: Source
> Versions: unspecified
> Environment: Operating System: Other
> Platform: Other
> Reporter: jean-yves mulvet
>
> 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.
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
