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=17077>. 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=17077 Code page problems under WebSphere z/OS ------- Additional Comments From [EMAIL PROTECTED] 2003-02-17 11:47 ------- Hi, I don't expect that the codepage is hard coded. I tried it like this to see if it overcame the problem and it did. I would be grateful if this could somehow be incorporated into Cactus. How this is done would be up to a Cactus contributor like yourself. Externalizing it into a property may be the best way. The reason why the default character set is not working in this case is because HTTPClient is keeping all the encoding in ASCII. When I first started testing Cactus on WebSphere z/OS I encountered encoding problems with HTTPclient. I raised a Bugzilla report and the developers for HTTPclient chose to correct the problem by keeping all encoding in ASCII. This works fine. However, when Cactus defaults to the EBCDIC code page for z/OS it is converting an ASCII response and not an EBCDIC one and the outcome is garbled. I hope this makes things clearer. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
