emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs-25 b6b47AF: Properly encode/decode base64Binary data in SOAP


From: Alex Harsanyi
Subject: Re: emacs-25 b6b47AF: Properly encode/decode base64Binary data in SOAP
Date: Mon, 14 Mar 2016 19:58:21 +0800

2016-03-14 17:15 GMT+08:00 Michael Albinus <address@hidden>:
> Andreas Schwab <address@hidden> writes:
>
>> Eli Zaretskii <address@hidden> writes:
>>
>>> Andreas, is it possible to move the decoding of originator from
>>> soap-client to debbugs?
>>
>> That needs to be answered by its author.
>
> As explained in my other message, originator (and other attributes)
> could be sent by the debbugs server as either xsd:string or
> xsd:base64Binary. debbugs.el does not know which encoding has been
> applied, it must trust on consistent soap-client.el decoding.

The decoding in soap-client is consistent, even though not in the way
you would like it :-)

  * if it is told that a value is a string, it will return a string,
  * if it is told that a value is a byte array it will return a byte
array (unibyte string)

To use another example, if the SOAP server chooses to send all
parameters as strings:

    <example xsi:type="xsd:string">1234</example>

soap-client will decode them as strings, even though to the human
reader it is "obvious" that it is a number:

   '(example . "1234")

I think the problem here is that the debbugs server encodes utf8
values as base64, even though the message envelope is utf8 XML and
could handle them as normal strings.   debbugs.el does not want to
know about this, so expects strings to be strings.  soap-client.el is
caught in the middle.

I would also like to reiterate that base64 encoding can be used for
other things, such as images, and it would not be appropriate to
decode those as utf8 (not to mention that such a decoding might fail).

Best Regards,
Alex.

>
>> Andreas.
>
> Best regards, Michael.
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]