RE: CRLF in <string> -- XML vs XML-RPC

As far as I am concerned (ie. maintaining the php-xmlrpc lib):

+ by default I encode using &#xxxx; notation EVERY char outside ASCII range when sending. That means, for 8 bit charset (php defaults to iso-8859-1 basically), chars <= 32 and >= 160. It is the best solution I could come up to make sure the charset transcoding errors are kept to a minimum. Plus CR LF are always sent and received as-is.
The receiving end should decode the payload (since it is full ascii nobody , and if the unicode code point is not available in the charset that the client app desires, it is up to it to decide what to do with it.

Note: the php application can, when using the lib, specify it desires to encode sent data as iso-8859-1 or UTF-8, in which case I do not convert \r or \n chars to their code point representation - and I do not normalize upon sending, either.

+ when receiving, the php xml parser is used. It is expat-based. As far as I can tell, i does not normalize CR\LF while decoding (but, of course, if the sending application has normalized it, I get what they sent)

+ the consensus on the spec is indeed 'that frase is crap - for binary data go base64'

Bye
Gaetano


  -----Original Message-----
  From: [email protected] [mailto:[email protected]]On Behalf Of John Wilson
  Sent: Monday, May 07, 2007 9:36 AM
  To: [email protected]
  Subject: Re: [xml-rpc] CRLF in <string> -- XML vs XML-RPC



  On 6 May 2007, at 22:56, [email protected] wrote:

  >
  > So, enough of the background. I'm posting because I have recently 
  > been told
  > that many or most XML-RPC servers see "\r\n" at the XML-RPC 
  > application
  > level. So I want to poll: In existing implementations, if
  > <string>\r\n</string> comes over the wire, does the XML-RPC 
  > application
  > code see "\r\n" or "\n"? And does the implementation use standard
  > XML parsing code or custom XML-RPC code?
  >
  > On the sending side, you can defeat XML's attempts to normalize line
  > endings by sending the five characters &#x0d instead of the character
  > \r. That brings you closer to the spirit of the "binary data" 
  > paragraph
  > in the XML-RPC spec. Does anybody do that?
  >
  > I'll start. I maintain the XML-RPC For C/C++ libraries. As far as I
  > know, they have always presented \r\n to the application as \n on the
  > receiving end, and it's because they use Expat and Libxml2 XML
  > parsers. On the sending side, if the application presents a string
  > containing "\r\n" in the value for a <string>, those two characters go
  > onto the wire.

  Bryan,

  I wrote and maintain MinML-RPC ( a server only implementation written 
  in Java which is mostly used in intelligent instruments) and the 
  Groovy XML-RPC implementation (server and client also written in 
  Java). Both use my MinML XML parser which normalises CRLF and CR to 
  LF as per the XML spec. Neither implementation escapes CR when 
  sending a <string>.

  I believe that the Apache Java XML-RPC implementation does the same 
  as he above. However the Apache implementation uses the standard Java 
  XML parsing API which allows arbitrary parser implementations to be 
  used so it is possible (but extremely unlikely) that some deployments 
  could behave differently as far as CRLF normalisation is concerned.

  The evidence from this list is that this behaviour does not cause 
  problems in practice (I don't remember there ever being a user 
  problem concerning this being posted on the list).

  Cheers

  John Wilson



   

[Non-text portions of this message have been removed]



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/xml-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/