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

[Ian Hickson]

On Sat, 19 Sep 2009, Michael A. Puls II wrote:
>
> 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.

Sites that want to use registerProtocolHandler() must use UTF-8.


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

I could see that as being mildly useful, though I would be concerned with 
the phishing risk. It seems that in most cases, the UA could just reuse 
the favicon of the page that registered the handler, though, maybe 
refreshing it from the page of the handler after the first time it is 
used. Also, it's unclear how we'd let the icon get updated when the site's 
icon changes; if we honour HTTP caching semantics or have a forced 
lifetime, then we have a privacy leak (a hostile site could maybe register 
a handler forcibly using a variety of induced-click techniques, or using 
social engineering, and then would just need to listen to the regular 
pings from the client updating the image), and if we don't ever update the 
image, then instead we have an out-of-date icon which could be worse than 
no icon at all.


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

The UA can already keep track of the page from which the user registered 
the handler, which seems suitable.


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

Always use GET. You're only sending a URL anyway.


> 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.

Why can't the server just do that server-side? That way it doesn't have to 
worry about updating clients later if it wants to support more features.


> 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.

Not sure what you mean here.


> 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.

If a site wanted to support these, it need but provide a CGI script that 
parsed the mailto: URL and redirected the user to the appropriate server. 
It could even support other encodings.


On Tue, 22 Sep 2009, Michael A. Puls II wrote:
> 
> Say the user sees that things are not working right with the handler. 
> The user goes into the options to see what's doing with the handler 
> settings and notices the link. The user clicks on it. Then, on the page, 
> it says "Attention: We've changed some things with what our server 
> accepts from our protocol handler. You need to register the handler 
> again by clicking here to get the updated version" for example. User 
> does and is happy again. :)

This seems highly optimistic. I think a more likely scenario is user finds 
things are broken, user goes whining in a forum, someone there points them 
to the site that they are whining about, and on the site there's a notice 
or something. Or, the user finds it's broken, and they just go straight to 
the site and try to reregister, and it "fixes" itself (with the addition 
of a new handler).

I don't think the link you're suggesting would get much if any traffic.

I'm not sure why a handler would break though. I mean, there's very little 
that can change. Sites can always just do redirects.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'