[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Re: Using base64 encoding with Frontier::Client
Hi Chris,
we where just trying to reproduce what you mentionned and could in fact
reproduce the new line break error. We tested what you suggest here and
can confirm it works here too.
We have now added some more comments to the perl demos.
Regards
Michele
Chris Cobb wrote:
> It turns out that by adding an empty second argument string to the
> MIME::Base64::encode() method, it is possible to generate an encoded
> string that does not contain line breaks. Using this mechanism, when
> combined with using the Frontier::Client::base64() method to create
> a <base64> data container, solves the problems that I was seeing.
>
> I guess it helps to RTFM ;-/ And thank you for creating such a nice
> message system that provides support for us Perl hackers!
> Chris
>
>
> Earlier, on 04-Apr-2006 at 2:51 AM, I wrote:
>> Greetings,
>>
>> We are starting to use xmlBlaster, and are using version 1.1.1.
>> I need to publish a serialized Perl object in a <base64> value. I
>> am using the Perl Frontier::Client module to publish the message.
>> However, the <base64> value returned to my subscriber Perl script
>> does not work: it appears that xmlBlaster has modified the content.
>>
>> When I capture data on the wire, the original serialized and base64
>> encoded object published to xmlBlaster appears in the first example,
>> below. The encoded data has one line feed between "...VJO" and "CIE..."
>> (in case email adds extra line breaks the first example should be four
>> lines, and the second example is one single line).
>>
>> Capturing data sent to the subscriber shows that the string has been
>> modified to become "...VJO/CIE..." which fails to decode successfully
>> when the message is received. (As a test, changing the "/" back into
>> a linefeed in the subscriber does allow the message to be successfully
>> decoded and converted back into a Perl object.)
>>
>> As an alternative, if I base64 encode the serialized Perl object and
>> publish it in a <string> value, the subscriber DOES get the original
>> value returned. However, in this case, Frontier::Client encodes the
>> the string a second time. It then requires TWO decoding calls in the
>> subscriber before the data can be successfully converted back into a
>> Perl object.
>>
>> Is there a trick to publishing <base64> values? Or a workaround to
>> prevent overhead of encoding and decoding <string> values twice?
>>
>> Thank you,
>> Chris
>>
>> #-----------------------------------------------------------------------
>> # Excerpt: Message published to xmlBlaster (data on the socket)
>>
>> <param><value><base64>NjUABQQRBURlYnVnAwAAAAQKB0RFQlVHOiAAAAAGUFJFRklYBQAAAAZJTkRFTlQIgQAAAARXQVJO
>>
>> CIEAAAAFTEVWRUw=
>> </base64></value>
>> </param>
>>
>> #-----------------------------------------------------------------------
>> # Excerpt: Message returned to subscriber (data on the socket)
>>
>> <param><value><base64>NjUABQQRBURlYnVnAwAAAAQKB0RFQlVHOiAAAAAGUFJFRklYBQAAAAZJTkRFTlQIgQAAAARXQVJO/CIEAAAAFTEVWRUwAAA=</base64></value></param>
>>
>>
>> #-----------------------------------------------------------------------
>>
>
>
>