Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Hi, thanks for your work on RPC::XML. We are using it in a project as a middleware layer between the app servers and web/mobile front end servers.

    We had a problem with sending German umlauts in strings. The XML parser on the receiving end was throwing errors. We temporarily fixed this by overriding the methods in RPC::XML::text to HTML::Entity::encode/decode everything. This works out alright, but I was wondering whether your recent changes with respect to the encoding headers might fix this?

    Maybe you s

    • That's a good idea. I think the encoding-header changes will help you, yes. I would be interested to hear back from you if you get the time to test it.

      (Prior to this, the only reliable way to transfer non-us-ascii strings was to encode them as base-64 and decode them at the destination.)

      --

      --rjray

      • We had a lot of problems with encoding but in the end got it to work.

        The Website http://www.lottospielen-nds.de/ [lottospielen-nds.de] is now in production. Front-End-Server and App-Servers talk via your Module :)

        However we sometimes get these errors: not well-formed (invalid token) at line 1, column 802, byte 802. I cant look at the actual data in the live system. But the data that should be transfered looks alright. Do you know some kind of transition that we can apply to all data so that we at least make sure that something gets transfered via the RPC-Call.

        Again thanx for your work!