Hi,
As maximi89 pointed out on IRC various times, when clicking on a link in
the standalone player, passing the URL to the browser doesn't work. The
reason is that the whole URL is URL-encoded before inserting it into the
shell command. That *can't* possibly work.
The purpose of URL encoding is to include characters, which normally
would affect the semantics of the URL string ('/', ':', '?', '&', '#')
or of the HTTP request (' ', '\r', '\n') as a literal piece of one URL
component. (For example in the file name, or in a part of the CGI query
string.) The latter group will automatically be escaped by the browser
when building the HTTP query; so the escaping is safe here. Encoding
characters in the former group however changes the meaning of the URL,
as seen by the browser and/or the web server. It is *not* allowed to
gratuitously encode these characters before passing the URL to the
browser.
To make it very clear: URL escaping is *not* intended to make an URL
safe for passing through the shell -- and it can't be (mis)used for this
purpose in a generic fashion. Characters like '&' or '#' would have to
be escaped for the shell, but that would break the URL. There is no way
to safely pass a URL through the shell without applying some shell
quoting.
We can't automatically apply shell quoting however, as the shell command
for lauchning the browser is provided by the user -- we don't know in
what context the URL will be inserted. For the same reason, we can't use
exec() to avoid shell parsing.
So, what to do about this mess?
0.) Give up the whole idea of using a plain shell command; find some
other way to specify the invocation, that gives us more semantics to
work with. (Insert some handwaiving here.)
1.) Encode only those characters that do not change the meaning of the
URL; and bail out if the URL contains any other characters that cannot
be safely passed through the shell. Could be quite many though.
2.) Encode only those characters that do not change the meaning of the
URL; and rely on the user to apply shell quoting around the URL in the
provided command, so the problematic characters don't get interpreted by
the shell. (Luckily, all characters that can escape either single- or
double-quoted shell strings should be safe to encode, as far as I can
see.)
3.) Both 1. and 2., using different magic sequences in the user-provided
shell command. (That would provide a smooth and safe transition path.)
Thoughts?
-antrik-
_______________________________________________
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
