| Subject: | Double encoding protection breaks encoding of strings that 'looks like' xml |
The root causes of double encoding problems are hard to find, but the current approach is a
'band-aid' that breaks the encoding of any string that "looks like" it's already been encoded.
That's a nasty bug because the effects are subtle.
I suggest you use SOAP::Lite to do the encoding but add an optional code-ref hook. That can
then be used to perform the current double encoding protection hack and/or just perform a
check and issue a warning. The warning would help people find the root cause of any double
encoding that might occur.
The warning could be on by default (since sending data that looks like "&foo;" is quite rare)
but editing that data, as is done now, should *not* be the default.
Please add a test to cover this, i.e., round-trip some data that contains "&", perhaps as a
campaign name, and see that it's returned to the application as "&"
(If you'd had test coverage for this you wouldn't have needed to release 5.06!)