Bug 16716

Summary: swfdec doesn't handle uri encoding, leading to failures on file:///
Product: swfdec Reporter: Alexandre Rostovtsev <tetromino>
Component: libraryAssignee: swfdec ml <swfdec>
Status: RESOLVED FIXED QA Contact: swfdec ml <swfdec>
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: file displaying the current URL
swf file that tests whether encoded URLs work
swfdec-0.6.6-uri-encoding.patch

Description Alexandre Rostovtsev 2008-07-14 20:37:23 UTC
The symptoms: in Nautilus, double-click on a flash file that has spaces, question marks, or non-ASCII characters in its name (e.g. "ибражы.swf"). Swfdec-player says that "%D0%B8%D0%B1%D1%80%D0%B0%D0%B6%D1%8B.swf is not a Flash file."

The reason this is happening is that SwfdecURL is blithely ignorant of URI encoding. See http://www.w3.org/Addressing/URL/4_URI_Recommentations.html for a short introduction to the subject.

So when Nautilus calls 'swfdec-player file:///home/me/%D0%B8%D0%B1%D1%80%D0%B0%D0%B6%D1%8B.swf', and the URL gets passed to swfdec_url_new(), the resulting SwfdecURL ends up with "/home/me/%D0%B8%D0%B1%D1%80%D0%B0%D0%B6%D1%8B.swf" in its path field, which obviously doesn't exist on my hard drive, leading to failure.

There are two ways of fixing this situation.
The WRONG way would be to make swfdec-player pass invalid URIs ("file:///home/me/ибражы.swf") to work around swfdec_url's broken behavior.

The right way is to formally specify, for EACH string parameter and return value of swfdec_url_* functions, whether the parameter is "raw" or URI-encoded, and to put in code to do the appropriate conversions. This needs to be thought out carefully so as not to break existing uses too much.
Comment 1 Benjamin Otte 2008-07-14 23:58:58 UTC
Created attachment 17679 [details]
file displaying the current URL

Looks like we'll want implement this as close to the WRONG way as possible.

The reason for this is that SwfdecURL is meant to do what the Flash player does when handling urls. And the Flash player happily puts all the characters into the URL as they are ignoring (as usual) any standards out there.

But we definitely want to have something like swfdec_url_(from|to)_real_url() and make swfdec_url_from_input() use this.
Comment 2 Alexandre Rostovtsev 2008-07-15 02:04:02 UTC
(In reply to comment #1)
> Created an attachment (id=17679) [details]
> The reason for this is that SwfdecURL is meant to do what the Flash player does
> when handling urls. And the Flash player happily puts all the characters into
> the URL as they are ignoring (as usual) any standards out there.

I don't think you understood the problem. The issue is not with how flash files are interpreted (so Adobe's plugin's behavior is not relevant to the discussion). The issue is with swfdec's API.

- The swfdec API includes functions with a parameter that can be interpreted both as a url (or part of a url) and as a pathname on disk (or part of a pathname).
- Which happily ignores the fact that urls are in URI encoding while local pathnames are in UTF-8. And there are no flags to specify which encoding the parameter is in.
- When local pathnames with non-ASCII characters are involved, the API provides no way to construct a SwfdecURL object whose url and path fields are both valid and consistent with each other.
- The SwfdecURL object is used, among other things, to specify where to load the flash files from.
- Outside the browser, Swfdec relies on its own loader classes to do IO. Those loaders assume that the fields of the SwfdecURL object are valid and consistent.
Comment 3 Alexandre Rostovtsev 2008-07-15 03:15:40 UTC
(In reply to comment #1)
> Created an attachment (id=17679) [details]
> file displaying the current URL

Interesting. Swfdec-mozilla shows a valid URL (file:///home/me/%D0%B8%D0%B1%D1%80%D0%B0%D0%B6%D1%8B.swf).

Meanwhile, both swfdec-player and Adobe's plugin show an invalid URL (file:///home/rostovts/ибражы.swf).

Now, Firefox certainly calls Adobe's plugin with a valid URL. My guess is that Adobe's plugin is printing the display form (.toString() or something) of the URL object instead of the actual URL string...
Comment 4 Alexandre Rostovtsev 2008-07-15 12:04:58 UTC
Created attachment 17683 [details]
swf file that tests whether encoded URLs work

As can be seen from this test file, Adobe's plugin expects URLs to be in valid URI encoding; if the URL is raw UTF-8, it won't load.

(Note that this example does not work on swfdec-0.6.6 for some reason)

---------
.flash filename="urltest.swf" bbox=400x100 version=7 background="#dddddd"

.action:
        var url1 = "%D0%B8%D0%B1%D1%80%D0%B0%D0%B6%D1%8B.swf";
        var url2 = "ибражы.swf";
        createTextField("t0", 0, 0, 0, 400, 20);
        t0.text = "Try click on the relative URLs below";
        createTextField("t1", 1, 0, 30, 400, 20);
        createTextField("t2", 2, 0, 60, 400, 20);

        var f1 = new TextFormat();
        f1.url = url1;
        t1.text = "Encoded URL works: " + url1;
        t1.html = true;
        t1.setTextFormat(f1);

        var f2 = new TextFormat();
        f2.url = url2;
        t2.text = "UTF-8 URL does not load: " + url2;
        t2.html = true;
        t2.setTextFormat(f2);
.end
.end
Comment 5 Alexandre Rostovtsev 2008-07-15 20:44:38 UTC
Created attachment 17694 [details] [review]
swfdec-0.6.6-uri-encoding.patch

Patch to fix the problem.

What it does:

1. Documents what fields, parameters and return values are supposed to be in filesystem encoding (the parameter to swfdec_url_new_from_input(), so long as it doesn't look like a URL), and which ones are URI-encoded (everything else).
2. Adds URI-encoding logic to swfdec_url_new_from_input()
3. Adds a function for converting URI-encoded strings to UTF-8
4. Adds URI-decoding logic to swfdec_url_format_for_display()
5. Adds URI-decoding logic to SwfdecFileLoader.

With this patch, swfdec-player correctly opens weirdly-named swf files both from Nautilus, from command line, and from its own file dialog. And even the window title is correct!

The patch is for swfdec-0.6.6, but it seems to also apply OK to 0.7.2.
Comment 6 Benjamin Otte 2008-07-17 12:38:06 UTC
Fixed in git.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.