[sr-dev] git:master: xmlrpc(s): option for replacing double lf with crlf

[Andrei Pelinescu-Onciul]

On Sep 23, 2009 at 15:37, Juha Heinanen <jh at 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 &#xD; ). 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 &lt; and &amp;. 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