On Sep 23, 2009 at 15:37, Juha Heinanen <jh(a)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