[whatwg] registerProtocolHandler - allow site to specify more info and do custom handling

[Michael A. Puls II]

Currently, registerProtcolHandler works like this:

navigator.registerProtocolHandler("protocol",  
"http://example.org/?uri=%s", "title");

However, this doesn't allow the site to specify some useful and important  
information about the site like:

1. What encoding the server expects. For example, uri= might expect the  
protocol link that was invoked in the browser to be interpreted as koi8-r  
instead of utf-8. This might be the case even if the page that uses  
registerProtocolHandler uses Windows-1251 for example.

2. The location of an icon like a favicon.ico file or png etc.

3. URI to a help page where the site explains how it makes uses of  
registerProtocolHandler and gives help and support contacts etc.

4. Whether to use "POST" instead of GET.

For #1, if the UA knows this, it can automatically make sure the data goes  
out to the server in the right encoding.

For #2, if the UA knows this, it can automatically provide the desired  
icon in its UI next to each entry in its protocol configuration dialog,  
for example.

For #3, if the UA knows this, it can automatically provide a site support  
link in its configuration dialog.

For #4, if the site would rather (or can only) accept POST data (to  
support longer data for example), then the UA can automatically oblige.

With that said, it'd be great if registerProtocolHandler supported a 4th  
argument that was an object of informative things.

For example, here are some things that could be supported:

var info = {
     "accept-charset" : "koi8-r",
     "icon" : "http://example.org/some_dir/favicon.ico",
     "help" : "http://example.org/support/protocol_handling.html",
     "requestMethod" : "POST"
};

navigator.registerProtocolHandler("protocol",  
"http://example.org/?uri=%s", "title", info);

Or, if you'd rather not use an object and just have more arguments:

navigator.registerProtocolHandler(
     "protocol",
     "http://example.org/?uri=%s",
     "title",
     "koi8-r",
     "http://example.org/some_dir/favicon.ico",
     "http://example.org/support/protocol_handling.html",
     "post"
);

Now, if you noticed, I used "automatically" above. This is because I think  
it would not be ideal to have a site register itself to handle a protocol  
only to have it not work by default and have the user find some page on  
the site that tells them how to manually configure options in each browser  
just to get things working.

To give an example, Opera supports registering certain webmails with  
"mailto". You currently have to edit an ini file to add more than the  
default and Opera doesn't support registerProtocolHandler yet, but what  
Opera does support is specifying an icon URI that gets used in the UI.

Opera also only supports GET at the moment and only supports emitting  
utf-8, but there are a few sites where POST and a different output  
encoding are desired by the webmail. For example, mail.ru would rather  
have POST being used and they only accepted koi8-r (and Windows-1251 as an  
option) up until recently.

With that said, if Opera supported registerProtocolHandler to add a  
protocol handler (mailto for example), having the site be able to specify  
an icon could be usable by Opera and other UAs.

If Opera ever supports using POST or emitting a different encoding, having  
the site say so would help so the user doesn't have to manually find out  
and configure all this stuff.

Now, Firefox supports registerProtocolHandler for adding handlers now.  
But, you can't configure post/get or icons etc. either. But, if you could,  
it'd be great to have the site say what to use. (You also have to use an  
about:config override to make handler work on any domain)

Finally, it's unfortunate that registerProtocolHandler can't optionally  
support a custom format string for the second argument and a format  
argument that's a function that gets the URI the user clicked on passed to  
it. It's also unfortunate that it's so domain restricted. That's a good  
default, but you can see that Firefox has an override for a reason.

For example, all of these webmails don't support what  
registerProtocolHandler emits. They only support individual values, which  
are different for each webmail.

"http://mymail.operamail.com/scripts/mail/Outblaze.mail?compose=1&did=1&a=1&to=&subject=&body=&cc=&bcc="
"http://mail.live.com/mail/EditMessageLight.aspx?n=&to=&cc=&bcc=&subject=&body="
"http://compose.mail.yahoo.com/?To=&Subj=&Cc=&Bcc=&Body="
"http://your_squirrelmail_server.com/src/compose.php?send_to=&subject=&body=&send_to_cc=&send_to_bcc="
"http://your_horde_server.com/horde/imp/compose.php?popup=0&to=&cc=&msg=&subject=&bcc="
"http://mail01.mail.com/scripts/mail/Outblaze.mail?composeto=&subject=&body=&cc=&bcc=&compose=1"
"http://win.mail.ru/cgi-bin/sentmsg?To=&CC=&BCC=&Subject=&BodyUTF8=&accel=1"
"http://your_roundcubemail_server/?_task=mail&_action=compose&_to=&_subject=&_body=&_cc=&_bcc="

In these cases, the URI format string in registerProtocolHandler would  
need a %key for to, subject, body, cc and bcc. The site could use %t, %j,  
%k and %l and %m for these for example. But, for the UA to understand  
those %keys (since the UA would only understands %s), a custom function  
would be needed that did the processing on the link the user clicked and  
returned the URI argument with the %keys replaced with the desired values.

So, what this means is that registerProtocolHandler is currently  
insufficient for a lot of webmails and will cause the webmails to have to  
change processing and do more processing on the server to support it  
(instead of just percent-decoding some values, they'll now have to  
percent-decode a whole URI, parse it and then percent-decode the  
individual values gotten). I believe this will make adoption of  
registerProtocolHandler way slower.

Further, for webmails that decide to never support what  
registerProtocolHandler emits in any way, it'd be nice if a user could  
insert a script (from a community wiki that provides it for example) that  
uses registerProtocolHandler with a custom format function that allows  
things to be automatically set up for that webmail anyway into the site's  
page.

Point being, registerProtocolHandler needs to be more robust. And,  
although this post is long, the requested additions are quite simple to  
specify.

Maybe these things can be supported in registerProtocolHandler v.02 once  
sites like the above prove that they are needed.

-- 
Michael