On Sep 23, 2009 at 15:37, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
Added "double_lf_to_crlf" config parameter. When set double LFs in the input xmlrpc strings are replaced with CR LF. This is needed to work around some xmlrpc buggy clients that don't escape CR ('\r' should be escaped to 
 ). When using one of those buggy clients, use double LF as an escape for CR LF and turn this option on.Turning this option on makes it also more compatible with kamailio tools (kamailio mi xmlrpc always converts double LF to CR LF).
andrei,
that you very much for adding support for those "buggy clients". if the clients really are buggy is controversial. xmlrpc spec has this:
What characters are allowed in strings? Non-printable characters? Null characters? Can a "string" be used to hold an arbitrary chunk of binary data?
Any characters are allowed in a string except < and &, which are encoded as < and &. A string can be used to encode binary data.
The xml spec has: http://www.w3.org/TR/REC-xml/#sec-line-ends : To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.
Also in http://www.w3.org/TR/REC-xml/#sec-common-syn : [...] S ::= (#x20 | #x9 | #xD | #xA)+
Note:
The presence of #xD in the above production is maintained purely for backward compatibility with the First Edition. As explained in 2.11 End-of-Line Handling, all #xD characters literally present in an XML document are either removed or replaced by #xA characters before any other processing is done. The only way to get a #xD character to match this production is to use a character reference in an entity value literal.
many client vendors have interpreted this to mean that \r is a perfectly valid character in xmlrpc string and need not to be escaped.
It's valid, but if it's not escaped then it won't be seen, because of the normalizing line breaks requirement for xml parsers.
Andrei