Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#5804 closed defect (bug) (invalid)

XML-RPC not handling & in URLs properly.

Reported by: denney Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.3
Component: XML-RPC Keywords: close
Focuses: Cc:


It seems the XML-RPC interface doesn't handle & signs in URL's properly when performing Pingbacks.

I'm trying to send a pingback from one site to another (that doesn't run Wordpress).

The URL for the Pingback is:


but the received XML is:

<?xml version="1.0"?>

As you can see, it's doing something funny with the & signs... I'm trying to figure out what's wrong but haven't come across anything yet.

I believe it has something to do with the "IXR_Value:getXml()" function... More specifically, the following lines:

            case 'string':
                return '<string>'.htmlspecialchars($this->data).'</string>';

Change History (7)

#1 @josephscott
12 years ago

  • Cc josephscott added

#2 @darkdragon
12 years ago

It is encoding the url, so that XML won't break. It probably would be better to use CDATA around the block instead, so that XML doesn't try to parse the & as an entity it doesn't understand.

What IXR is trying to prevent is breaking the parser on the other blog, which might not understand what '&' or any other entity means in the context of the URL. The XML parser doesn't know that '&' is part of an URL and is legal, it just sees an '&' with an illegal entity after it. You could then assume that the parser at the other end will crash on the XMLRPC, which is a bad thing.

The other blog should take &amp; and replace them with '&'. Or this blog should just encapsulate strings in CDATA blocks. It may or may not pose a problem with WordPress, since WordPress doesn't really use an XML parser (regex instead) and I'm unsure if IXR is smart enough to understand CDATA blocks.

#3 @denney
12 years ago

The thing that troubles me is the other blog system is using the IXR library... v1.7 beta in fact.

So this means that it's capable of encoding the &amp; but not capable of decoding it. Maybe I should submit it as a bug to the author the IXR library as well...

#4 @westi
12 years ago

This looks like we are double encoding.

Once before IXR encodes and once within.

We should be able to rely on IXR to encode the & for us I suspect.

#5 @denney
12 years ago

So this means the IXR library is not the issue?

I didn't end up submitting this as a bug to the author of IXR. I guess I don't have to now. :)

#6 @Denis-de-Bernardy
11 years ago

  • Keywords close added

is this still valid?

#7 @ryan
11 years ago

  • Milestone 2.9 deleted
  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.