WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#8013 closed defect (bug) (invalid)

CDATA block in post content trips up XMLRPC interface

Reported by: redsweater Owned by: josephscott
Milestone: Priority: normal
Severity: normal Version: 2.6.1
Component: XML-RPC Keywords:
Focuses: Cc:

Description

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.

Change History (5)

comment:1 @josephscott7 years ago

When I tried this using a simple PHP script the IXR XML-RPC library it sent <![CDATA[Hello]]> encoded as &lt;![CDATA[Hello]]&gt; 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.

comment:2 @redsweater7 years ago

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

comment:3 @redsweater7 years ago

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

comment:4 @josephscott7 years ago

  • Resolution set to invalid
  • Status changed from new to closed

comment:5 @josephscott7 years ago

  • Milestone 2.8 deleted
Note: See TracTickets for help on using tickets.