Bug 21489 – [CURL] WebKit fails to load file:/// URLs with Turkish locale (upstream bug)

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Thierry Vignaud]

webkit failed to load images in HTML pages if locale is switched to turquish ('tr' ISO code), whatever is the actual content. Aka the same content loads fine with other locales.

A simple 12 lines perl script show the page with images with all of the following locales: br cy cz de en_CA es et fi fr he it ja ko pl pt_BR ru th zh_CN zh_tW.

Only 'tr' locale failed.
Midori perfectly load the same HTML page in any locale but with 'tr' locale, in which case, it stays in 'loading' mode...

The attached two line test page exhibits this behaviour.

Versions tested: snapshot from mid september (r36309) and snapshot from a few minutes ago (r37381).

This bug was initially reported as Mandriva bug #44710 (https://qa.mandriva.com/show_bug.cgi?id=44710)

Tested on Mandriva 2009.0.

[Thierry Vignaud]

Created attachment 24205 [details]
This simple two line test page exhibits the bogus behaviour with tr locale

[Thierry Vignaud]

Created attachment 24206 [details]
source this file in order to switch to 'tr' locale

eg: (. ./.i18n.tr; midori file://$PWD/2.html)

[Thierry Vignaud]

Created attachment 24207 [details]
proper image of perl test case with C or fr locale (actually tested with 20 different working locales)

[Thierry Vignaud]

Created attachment 24208 [details]
bogus image of perl test case with tr locale

[Thierry Vignaud]

Interestingly, this bug only affect local images "<src..." links, not network remote ones as showed by running perl -pi -e 's!/usr/share/gtk-doc/html/cairo/home.png!http://webkit.org/images/icon-gold.png!' on the HTML testcase file.

Which probably explains why nobody ever reported it yet (require browsing a local file in turquish locale)

[Mark Rowe (bdash)]

Confirmed with r37431.  The problem *does* reproduce with remote images in my testing.

[Mark Rowe (bdash)]

I think this may be a curl bug.  With the Turkish locale set I see a console message from curl saying "Unsupported protocol".  With the default locale (US English) I do not see this message, and the image loads as expected.

This theory has further weight behind it because the following command fails in a Turkish locale, but succeeds in US:

[Turkish locale]
mrowe@mrowe-desktop:~$ curl file:///test
curl: (1) Protocol file not supported or disabled in libcurl

[US locale]
mrowe@mrowe-desktop:~$ curl file:///test
curl: (37) Couldn't open file /test

Given this, I don't believe that this is a WebKit issue.

[Mark Rowe (bdash)]

I rebuilt against the soup backend and the test case works as expected, which confirms that this bug is in the libcurl backend.  Since the bug is also reproducible in the curl command-line tool, the problem appears to be in libcurl itself rather than WebKit's use of the library.  A bug should be filed against libcurl in order to have this issue be fixed, and this bug shall be closed as INVALID as the issue is in an external component rather than in WebKit itself.

[Alp Toker]

Seems that curl is doing locale-aware testing of the protocol part of the URL, and 'i' (dotted i) in Turkish is not equivalent to 'i' in other locales.

While this is indeed a serious CURL bug, we can implement a workaround in WebCore, which is to pass CURL the URL with the protocol part converted to uppercase (FILE), where it doesn't exhibit the bug.

I'm willing to implement and test this workaround for our Turkish users, but only after there's evidence that the CURL bug has been reported upstream.

Please let me know when the issue is reported to the CURL developers so I can do that.

Cheers

[Thierry Vignaud]

It has been reported upstream a long time ago:
https://sourceforge.net/tracker/index.php?func=detail&aid=2154627&group_id=976&atid=100976

[Adam Williamson]

Update: it has been fixed upstream in curl, and I have backported the fix to Mandriva Cooker just now.

[Tanju Taþçýlar]

Thanks for the fix. 

Adam, I installed curl and libcul4 you backported in cooker on Mandriva 2009.0. I can confirm it is fixed. And so far I did not find any other problem wuth those new packages on 2009.0.

[Alp Toker]

I didn't have much luck implementing a reliable workaround in WebCore. We'll have to encourage the distributions to ship (and backport?) the fixed libcurl.

[Adam Williamson]

Alp: in case it helps, our version of the patch can be found here:

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/curl/current/SOURCES/curl-7.19.0-turkish.patch?view=markup

upstream committed it in three different (CVS...) commits, and trunk differs somewhat from 7.19.0, so other distros may find it helpful to have access to our patch.

[Gustavo Noronha (kov)]

Removing the Gtk keyword, since GTK+ doesn't use curl anymore.

[Brent Fulgham]

As this is (a) an upstream bug in libcurl, (b) not used for Gtk anymore, and (c) the fix in curl has been in the field for over 10 months, I'm closing.

Please reopen if anyone is still having problems due to this bug.