CDATA block in post content trips up XMLRPC interface

[redsweater]

This issue was originally discussed on my forums:

​http://www.red-sweater.com/forums/viewtopic.php?id=948

Summary: If a post contains a CDATA block it causes a "not well formed" parse error in WordPress.

I narrowed the issue down to a very simple test case, typing the following into the content of a blog post from MarsEdit causes a parse error in WordPress:

<![CDATA[Hello]]>

I confirmed that the same content also triggers the error if sent from another Mac desktop client, ecto.

By the time MarsEdit massages the content, it's literally:

&lt;![CDATA[Hello]]>

So, to reproduce the bug either paste the unmodified line into MarsEdit or else use an XMLRPC testing tool to send a post with the literal content as escaped above.

As far as I can tell this should be legal XML content, but it trips up WordPress. I also notice that it trips up Movable Type, but since I had started a conversation with Joseph Scott about this, I'll use this as the exploration vector for the bug.

[josephscott]

When I tried this using a simple PHP script the IXR XML-RPC library it sent <![CDATA[Hello]]> encoded as <![CDATA[Hello]]> which worked fine. The raw database post content was <![CDATA[Hello]]>. I think the right think to do then is to encode both sets of angle brackets.

[redsweater]

Interesting discovery. I don't think it's improper to leave the &gt; unencoded, but if that turns out to be the source of the problem in WordPress, maybe I will change MarsEdit's behavior.

I could have sworn I reproduced the same parse error from ecto, which does encode the &gt; as you describe, but now I can't seem to do it again.

Daniel

[redsweater]

My mistake! The > character doesn't usually need to be escaped, but DOES need to be escaped if it's part of the sequence ]]>, as it is in the CDATA block.

I think we can safely close this with the conclusion that clients such as MarsEdit must be careful to escape the > in a construction like this.

Thanks,
Daniel