Make WordPress Core

Opened 14 years ago

Last modified 5 years ago

#11734 new defect (bug)

trackback_rdf() for IDN (xn--) Domains produces invalid HTML

Reported by: lathspell's profile lathspell Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Comments Keywords: needs-testing
Focuses: Cc:



The trackback_rdf() function from wp-includes/comment-template.php wraps the "<rdf:RDF>...</rdf:RDF>" output inside "<!-- ... -->" HTML comments, probably to be safe as not all Browsers understand them.

When using Wordpress 2.9.1 on a site with an international domain name [1] that contains special characters like German "Umlauts" like äöü, this domain name is written as e.g. for tä

Now the output of trackback_rdf() suddenly gets a "--" which is the SGML/HTML comment separator mark [2]. Firefox 3.5.6 e.g. sees this as the end of the comment and therefore shows the final "-->" as text to the user.

As the whole RDF tag is supposed to be invisible for the user, it's a bug in Wordpress :-(

Here is an real world example output:

                     <p class="post-tags">

				  <p class="post-info">
				    <rdf:RDF xmlns:rdf=""
			<rdf:Description rdf:about=""
    trackback:ping="" />
</rdf:RDF>				  -->

Sadly I have not yet come up with a solution. PHPs urlencode() does not escape a double dash - which is ok as its usually perfectly valid. Maybe someone with RDF experience has a good idea.





Attachments (3)

comment-template.php.patch (912 bytes) - added by dwright 14 years ago.
At revision 12940, convert '--' to hex
11734.diff (1.4 KB) - added by mdawaffe 11 years ago.
11734-2.patch (1.4 KB) - added by brokenflipside 8 years ago.

Download all attachments as: .zip

Change History (13)

#1 @hakre
14 years ago

Nice find!

IDN Related ticket: #10690

#2 @dwright
14 years ago

What steps can I use to reproduce this?

That said, I believe the attached patch would resolve this issue.

Additionally, using the IDNA plugin (which enables the use IDN's (international domain names) in WordPress) would resolve this.

14 years ago

At revision 12940, convert '--' to hex

#3 @dwright
14 years ago

  • Cc david_v_wright@… added
  • Keywords has-patch added

#4 @nacin
14 years ago

  • Milestone changed from Unassigned to Future Release

#5 @codestyling
13 years ago

  • Cc codestyling added
  • Keywords needs-patch dev-feedback added; has-patch removed
  • Version set to 3.1

IDN handling is different related to Browsers! WebKit based browser like Safari and Chrome work with PunyCode URL's but others like IE, Firefox and Opera doesn't.
This is a problem of Cross Site Scripting detection and can be realize and tested, if the Blog is configured to an PunyCode Url.

example out of a case I did investigate:
IDN: http://с-проект.рф
PunyCode: http://xn----jtbpoegeo.xn--p1ai

If you try to call a JSON request like this example with the generated admin_url() out of WordPress, which would become the PunyCode one:

	new Ajax.Request('http://xn----jtbpoegeo.xn--p1ai/wp-admin/admin-ajax.php' ?>', 
			parameters: {
				action: 'get_download_section'
			onSuccess: function(transport) {		
			onFailure: function(transport) {
				alert('JSON security bug')

and the answer is correct 'application/json' with correct JSON content, than this fails on all browsers except WebKit based!
If you try it with the original IDN Url like:

	new Ajax.Request('http://с-проект.рф/wp-admin/admin-ajax.php' ?>', 

it works now for all other browsers but fails now on WebKit based.

My suggestion will be a conditional convertion back to IDN, if browser is not WebKit based.
I did this inside my WordPress plugin "Codestyling Localization" and it works now in any case. I did use the class idna_convert from Matthias Sommerfeld for easy decode of PunyCode admin url's in such a case.

Please check it also in relation to #11734 / #10690 / #14648 because this may also affect the flash uploader feeded with PunyCode url's instead of IDN for some browser!

#6 @solarissmoke
12 years ago

  • Keywords close added; needs-patch dev-feedback removed

The wrapping in comments was actually done by the themes that used trackback_rdf(). Seeing as those are no longer bundled in core, and the currently bundled themes don't use trackback_rdf(), this can probably be closed?

11 years ago

#7 @mdawaffe
11 years ago

  • Keywords has-patch 2nd-opinion added; close removed


  • Hexifies all --
  • Removes wptexturize() (it's in the filter already).

#8 @nacin
10 years ago

  • Component changed from General to Comments

Patch seems appropriate.

#9 @chriscct7
9 years ago

  • Keywords needs-refresh added; has-patch 2nd-opinion removed

#10 @brokenflipside
8 years ago

  • Keywords needs-testing added; needs-refresh removed

Patch applied fine, but VVV wasn't happy with my attempting to spin up äöü.dev as it resulted in similarly broken URLs as demonstrated above. So I am going to test outside of VVV and will report back.

Note: See TracTickets for help on using tickets.