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

[Michael A. Puls II]

On Mon, 05 Oct 2009 07:27:08 -0400, Ian Hickson <ian at hixie.ch> wrote:

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

O.K., so you definitely, no doubt about it, want to make that a  
requirement. If so, fine, just want to make sure.

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

O.K., there can be some guidelines/tutorials that recommend that the page  
that registers the handler is also the help page so that UAs can use that  
info if needed. It could also be recommended in such a tutorial that the  
page should use the desired favicon so UAs can use it if they want (and  
how they want and with what restrictions they want)

>> 4. Whether to use "POST" instead of GET.
>
> Always use GET. You're only sending a URL anyway.

But, with POST you can send longer data (depending on the server and its  
config). Since %s is a percent-encoded version of data that's usually  
already percent-encoded (in parts of the URI), a lot of that length is  
lost in just percent-encoding (lots of "%2525"s for example).

Also, the devs for one webmail even prefer POST data as they said that  
it's less revealing when submitting through a proxy. But, I never  
validated that.

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

I'm not saying they can't. More like, I'm saying they won't or cannot in a  
timely manner and that there's a better chance of support if they don't  
have to change their server-side scripts and can just use a little JS.

Also, with your user hat on, you should see why it'd be great to have a  
standardized function to do customize handling yourself to workaround lack  
of support for %s.

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

"file:///c:/documents%20and%20settings/user/desktop/test.html" can't  
register a "mailto" handler for "http://foo.org/?uri=%s" in Firefox by  
default. The URL argument has to be on the same domain or it is denied.  
Firefox does have an override though in about config, which you must use  
to get that to work.

I see the spec leaves this up to the UA to do what it wants though, so  
nevermind.

I also seem to remember that the intent was that the registered handler  
would only be invoked when clicking on links on pages on the domain that  
registered the handler. That would mean that the protocol handling would  
only work on the site's pages and no other sites. However, I don't see  
that in the spec and that's not how it works in FF, so nevermind.

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

Yep, this is basically what Gmail does and works great. It basically  
converts "https://mail.google.com/mail/?extsrc=mailto&url=" into what's  
really supported, which is:  
"http://mail.google.com/mail/?compose=1&view=cm&fs=1&to=&su=&body=&cc=&bcc=".

However, it doesn't seem like many other sites will do that or even get  
the mailto URI parsing right. They can't even fix the bugs in their  
regular compose URIs.

(I hate to name names, but mail.live.com and mail.yahoo.com are absolutely  
horrible at getting things right in these cases. But, as you know, users  
still insist on using those sites, so standardized workaround capabilities  
sound great to me. You can read through <http://operawiki.info/WebMailto>  
to get an idea of some of the problems.)

If you could do custom handling with registerProtocolHandler, you could  
register a handler yourself and do the processing as you like and do any  
workarounds that are needed for the site.

The alternative will be for each UA to support its own advanced  
registerHandler function. Was trying to avoid that though. But, I guess  
sites could wrap them all into a single function.

In short, I'm saying that registerProtocolHandler is currently useless for  
registering most webmails as a "mailto" handler. Now, I think registering  
webmails as "mailto" handlers is a very, very, very important use case. It  
perhaps even deserves its own function that can support existing webmail  
compose URIs.

IMO, fwiw.

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

O.K. Thanks

-- 
Michael