Incorrect hanling of CDATA sections

Description

Rome incorrectly handles the CDATA encoded content and escapes the values so
they end up doubly escaped.

e.g.
<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
<channel>
...
<item>
<link>http://serv/cgi?bob=fred&amp;jane=freddy</link>
</item>
<item>
<link><![CDATAhttp://serv/cgi?bob=fred&jane=freddy]></link>
</item>
</channel>
</rss>

when dumped/retrieved the two entries should be the same however the second
items link has the & escaped whereas the first is correct and as expected (the
escape sequence has been removed)

SyndFeedImpl.entries[0].link=http://serv/cgi?bob=fred&jane=freddy
SyndFeedImpl.entries[1].link=http://serv/cgi?bob=fred&amp;jane=freddy

That is when retreived and no longer inside XML the CDATA section should be
returned as-is without the CDATA section wrapping. Elements without this should
have any escaping removed.

test case attached.

Environment

None

Attachments

2

Activity

Show:

Martin Kurz October 8, 2013 at 5:32 PM

We recently moved to GitHub. The issue is now located here: https://github.com/rometools/rome/issues/134

Former user September 15, 2011 at 6:55 PM

Attachment romeTest.tar.gz has been added with description: http://java.net/jira/secure/attachment/26765/romeTest.tar.gz

Former user September 15, 2011 at 6:55 PM

Attachment romeTest.tar.gz has been added with description: http://java.net/jira/secure/attachment/26766/romeTest.tar.gz

teilo August 13, 2009 at 8:14 AM

The bug is actually in the XmlFixerReader class. It blindly attempts to replace
all & that are not followed by a ; with &.

While this is an admirable approach to fixing bad XML it MUST NOT do this for
content inside a CDATA section that doesn't need escaping.

teilo August 12, 2009 at 2:13 PM

Created an attachment (id=42)
test case (with correct compiler settings)

UNRESOLVED

Details

Assignee

Reporter

Fix versions

Affects versions

Priority

Created August 12, 2009 at 2:05 PM
Updated October 8, 2013 at 5:32 PM
Resolved August 13, 2009 at 8:14 AM