Bugzilla Bug 150404

http://alexander.skwar.name/~askwar/stuff/text-with,comma
http://alexander.skwar.name/~askwar/stuff/text-with

Run:
/usr/bin/firefox http://alexander.skwar.name/~askwar/stuff/text-with,comma

Expected result:
The URL http://alexander.skwar.name/~askwar/stuff/text-with,comma is loaded in
the browser. Text displayed:
If you see this text, the client loaded the complete URL, ie. WITH the comma
(,) in the URL.

Actual result:
URL http://alexander.skwar.name/~askwar/stuff/text-with is loaded. Text
displayed:
If you see this text, the client shortened the URL before the , (comma).

Assumed explanation:
The , in the URL is causing problems. Although I did not test this, I assume
that this bug will also effect seamonkey and any other application using
mozilla-launcher. When I use the original firefox from http://mozilla.com/, I
don't have this problem.

I'm currently using mozilla-launcher-1.52-r1.

The bug only occurs, when there's already another firefox running (for the
current user, I assume). If this starts up a new firefox session, it works just
fine.

The original firefox doesn't do any magic with openURL and such. Instead, when
"firefox http://alexander.skwar.name/~askwar/stuff/text-with,comma" is run, the
folllowing gets eventually executed:

    ./firefox-bin http://alexander.skwar.name/~askwar/stuff/text-with,comma

Maybe this could be adopted for mozilla-launcher?

If not, then "special" characters, like the , (comma), should be urlencoded. At
least for the URL given as a test case, 

   http://alexander.skwar.name/~askwar/stuff/text-with%2Ccomma

works as well.

Hmm... Where's the advantage of using mozilla-launcher over using
/usr/lib/mozilla-firefox/firefox? I modified /usr/bin/firefox and did:

+++ /home/alexander/tmp/firefox 2006-10-08 12:19:21.000000000 +0200
@@ -4,7 +4,12 @@
 # but OOo brokenness makes it necessary to use a stub instead:
 # http://bugs.gentoo.org/show_bug.cgi?id=78890

+set -x
+
 export MOZILLA_LAUNCHER=firefox
 export MOZILLA_LIBDIR=/usr/lib/mozilla-firefox
 export MOZ_PLUGIN_PATH=${MOZ_PLUGIN_PATH:-/usr/lib/nsbrowser/plugins}
-exec /usr/libexec/mozilla-launcher "$@"
+#exec ~/tmp/mozilla-launcher "$@"
+
+exec /usr/lib/mozilla-firefox/firefox "$@"
+

What will not work?

*** Bug 149215 has been marked as a duplicate of this bug. ***

Any idea, about when something might be done about this? I'd also like to know,
what mozilla-launcher is good for - what would break, if it were dumped?

Ping?

Created an attachment (id=101759) [details]
patch to mozilla-launcher to escape commas in urls

(In reply to comment #7)
> Created an attachment (id=101759) [edit] [details]
> patch to mozilla-launcher to escape commas in urls
> 

Having had a closer "look" at this, I dislike this patch. Reason: Up to now
firefox eventually runs the openURL remote command. Users might know this and
might make use of this. So a user might call "firefox
http://gentoo.org/,new-tab" to have http://gentoo.org/ opened in a new tab. If
this patch is applied, this won't work anymore.

URLs including ')' in them cause mozilla-launcher to fail as well.

(In reply to comment #8)
> Users might know this and might make use of this.
> So a user might call "firefox http://gentoo.org/,new-tab" to have
> http://gentoo.org/ opened in a new tab.

Talking about a command line interface, the cleaner approach would be something
like "firefox --new-tab http://gentoo.org/" or something similar.
Sure, that would break backward compatibility, but I believe it's worth it.
It would be nice if we could make the launcher intelligent enough to handle
this--

(In reply to comment #8)
> Users might know this and might make use of this.
> So a user might call "firefox http://gentoo.org/,new-tab" to have
> http://gentoo.org/ opened in a new tab.

Talking about a command line interface, the cleaner approach would be something
like "firefox --new-tab http://gentoo.org/" or something similar.
Sure, that would break backward compatibility, but I believe it's worth it.
It would be nice if we could make the launcher intelligent enough to handle
this--—if the launcher is indeed needed, which I know nothing about yet.

Fixed in 1.56

Please reopen and revert the patch. This breaks all links in mails that have
commas in them. Until a correct way to handle new-tab is found. My guess is
that there are more users using firefox as a browser and tries to open links
from a mail client then there are users using the ",new-tab" way.

A better way would be to not filter commas but rather the valid command that
can be sent to openURL.

(In reply to comment #13)
> Please reopen and revert the patch. This breaks all links in mails that have
> commas in them.

It does? How so? I just verified, and when I run

  firefox http://alexander.skwar.name/~askwar/stuff/text-with,comma

the URL "http://alexander.skwar.name/~askwar/stuff/text-with%2ccomma" is
loaded. It shows the contents of the file "text-with,comma". Exactly like
expected.

When and where does the patch NOT work?

Anyway - a better idea might be to NOT fiddle at all with the URL *AND* also
*NOT* use openURL() at all anymore. As written in the comments of this bug, the
plain "firefox" script from Mozilla.com works just fine. The mozilla-launcher
covers just for some corner cases.

> Until a correct way to handle new-tab is found. My guess is
> that there are more users using firefox as a browser and tries to open links
> from a mail client then there are users using the ",new-tab" way.

I don't understand. As it is right now, the ",new-tab" stuff doesn't work
anyway. Reason: ",new-tab" is converted to "%2cnew-tab". This is not a valid
openURL() parameter and thus interpreted as part of the URL.

> A better way would be to not filter commas

Sort of. If openURL() is used, commas have to be filtered.

Anyway. Please provide a testcase. Broken servers should not matter (only
broken servers don't handle the translation %2c -> ,).

My testcase is the following URL:
http://alexander.skwar.name/~askwar/stuff/text-with,comma

Try to load this URL and also:

http://alexander.skwar.name/~askwar/stuff/text-with

Well as far as I can tell, according to rfc2616 and rfc2396 the comma is a
reserved character that may not be escaped.

But any way if the openURL() call is depreciated then why break legal url's to
be compliant with openURL()? or see if openURL is in the call (possible?) and
only then filter ",","(",")"

(In reply to comment #15)
> Well as far as I can tell, according to rfc2616 and rfc2396 the comma is a
> reserved character that may not be escaped.

I'm still checking that. Care to point out, which sections of the FAQ mention,
that reserved characters may not be escaped?

I understand RfC 2396 so, that reserved characters (eg. "," or "?") are NOT to
be escaped, if they serve a special function. Eg. the "?" serves as a delimiter
in the Request URI as a delimiter between the "script name" and the query
string (eg. in http://example.com/foo.htm?bar=yep, the bar=yep is the query
string). In such a case, the "?" is not allowed to be escaped. In other cases
it can (or sometimes must) be escaped. The same holds true for "," (although I
don't know when or where the "," serves a special purpose IN REAL LIFE USAGE).

> But any way if the openURL() call is depreciated then why break legal url's to
> be compliant with openURL()?

Simple - because otherwise, they don't work. If you pass
"http://alexander.skwar.name/~askwar/stuff/text-with,comma" as a parameter to
openURL(), Firefox (& SeaMonkey) will try to open the URL
"http://alexander.skwar.name/~askwar/stuff/text-with". The ",comma" will be
interpreted as a parameter on how to open. Basically, Firefox will then check
if ",comma" is equal to ",new-tab" and as it's not and as openURL() doesn't
know anything about ",comma", it'll silently ignore it.

Result: http://alexander.skwar.name/~askwar/stuff/text-with is loaded.

To overcome this, the , needs to be translated to %2c.

> or see if openURL is in the call (possible?) and
> only then filter ",","(",")"

As long as openURL() is used, the "," (and also "(" and ")") always need to be
escaped.

Anyway - how about a testcase? Which URL breaks? All the URLs I tested worked.
Granted, compared to the some billion URLs there are on the internet, I only
tested a *VERY* minor fraction... :)

Here's another working URL:
http://www.spiegel.de/politik/ausland/0,1518,480652,00.html ->
http://www.spiegel.de/politik/ausland/0%2c1518%2c480652%2c00.html

(comment #16)
From the examples you've given it seems like the comma is used as a character
in the url instead as a delimiter. In my url (like this:
http://www.bovision.se/scripts/bovision/prenbesk.phtml?nnnnnn,nnnn&confirmed=1&OBJGUID=nnnnnnn&OBJTYPE=CMVILLA&nyabesk=1
(n=a digit, removed due to subscription info)) it is used as a delimiter.

rfc2616: 3.2.3 URI Comparison
rfd2396: 3.4. Query Component

However as you said in comment #14: openURL() doesn't work now so why keep a
fix for it that 1: doesn't work and 2: breaks other things?

Hm, I still don't quite understand.

The test URL you provided seems to be using PHP (because of the .phtml). When I
go to another test URL of mine, PHP (or Apache?) seems to translate the %2c to
a , just fine.

Compare http://digitalprojects.com/PHPInfo/index.php3?foo%2cbar=john.doe to
http://digitalprojects.com/PHPInfo/index.php3?foo,bar=john.doe. Scroll all the
way down to "PHP Variables". On both URLs, you'll find: _REQUEST["foo,bar"].

If I go to
http://www.bovision.se/scripts/bovision/prenbesk.phtml?nnnnnn,nnnn&confirmed=1&OBJGUID=nnnnnnn&OBJTYPE=CMVILLA&nyabesk=1
(ie. with ,), I get an error message:  Input string was not in a correct
format.

Could you provide a test case, please? Up to now, I'm not yet convinced, that
the , -> %2c translation is breaking things in the real world (although I of
course don't matter, as I'm not a dev...). Anyway, without a testcase, I
suppose it'll be hard to convince the devs that something is broken and should
be changed.

*** Bug 178224 has been marked as a duplicate of this bug. ***