non-latin CPT rewrite slugs fail `wp_safe_redirect`

[entr]

If you localize your custom post type rewrite slugs in non-latin language and pass it to wp_safe_redirect it will strip all non-latin characters and attempt to redirect to stripped location.

This can be easely reproduced if your custom post type supports comments and you submit a comment from post type single page as wp_safe_redirect is called after comment submission.

[SergeyBiryukov]

Related: #10690

wp_safe_redirect() passes the URL through wp_sanitize_redirect(). Could you give an example of an affected URL?

[entr]

Yes, with a rewrite set as:

..
'rewrite' => array( 'slug' => 'продукт', 'with_front' => false ), //BG localization for `product` (cyrillic)
..

wp_sanitize_redirect returns
http://blogdomain.com//post_name
instead of
http://blogdomain.com/продукт/post_name
which in my case causes infinite loop

[nofearinc]

I've tested a modified version ​of this snippet which works fine for resolving (and not breaking a list of test domains):

	$url1 = 'http://blogdomain.com/продукт/post_name';
	$url2 = 'xn--sorra-lqa.it';
	$url3 = 'xn--maana-pta.com';
	$url4 = 'xn--bcher-kva.com';
	$url5 = 'xn--caf-dma.com';
	$url6 = 'yahoo.com';
	$url7 = 'google.com';
	$url8 = 'dir.bg';

However, @nacin said that it's not compatible with the WordPress license, and the original PHP function is supported by PHP 5.3+ only.

I saw that Ryan ​was working on some IDNA encoder and there are probably other license-compatible solutions, but I'm not sure how much of an overhead would it be to add a 200-400 LoC class for this use case. Thoughts?

Still there are few more related tickets to that problem, but can't decide how urgent or widespread that is.