Open Radar

 
Summary:
When Safari requests a URL, e.g. for fetching an inline image, and the URL has non-ASCII characters that are not URL escaped, then when Safari provides the actual request on the wire, the URL has URL escapes that were generated from the bytes of the string after changing the composition of the characters from what they were in the HTML document.

Steps to Reproduce:
1. Visit http://wanderingcoder.net/projects/Radar/SafariUniComposition/ with Safari

Expected Results:
The image appears, as it does when the page is visited using e.g. Firefox or Chrome, because it was requested with:
GET /projects/Radar/SafariUniComposition/fe%CC%81lines.png HTTP/1.1

Actual Results:
The image does not appear, because it was requested with:
GET /projects/Radar/SafariUniComposition/f%C3%A9lines.png HTTP/1.1
which answers a 404

Version:
Reproduced on all three of:
Mac OS: Safari 9.1.1 (11601.6.17)
MobileSafari: iOS 9.3.2 (13F69)
MobileSafari: iOS 10.0 beta 1 (14A5297c)

Notes:
Workaround is to write the URL in the HTML document as "fe%CC%81lines.png", i.e. to properly escape it, as demonstrated in http://wanderingcoder.net/projects/Radar/SafariUniComposition/index2.html

I do realize Safari is already trying to compensate for invalid data, as the URL should be properly escaped in the first place, however some CMS apparently haven't got the memo and will blindly write the URL without escaping it… e.g. at the time of this writing the issue is still live at http://maliki.com/nouveau-mois-tipeee/ (the image just above the article does not load).

Last note: if you want to reproduce the issue on another server, be very careful as many processes may themselves canonicalize the composition of the file name, e.g. a Mac OS X host and/or an HFS+ filesystem will fold the Unicode composition, and may cause the problem to no longer be reproduced, or on the contrary cause the image not to load including when using other browsers.

Configuration:


Attachments: