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

[Ian Hickson]

On Mon, 5 Oct 2009, Michael A. Puls II wrote:
> > >
> > > 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)

This is the kind of thing for which implementation experience will be 
particularly useful.


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

How long a URL are you expecting people to be using with this?? I rarely 
see 4K URLs when downloading files or following mailto: URLs!


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

If they care about the privacy of their users, they should use TLS.


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

I think it's unrealistic to expect that an application provider would have 
more trouble updating a server-side script than it would be to expect the 
same application provider to update the JS of all its clients' 
configurations.


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

As a user, I'd think it'd be great if I never had to see JS at all.


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

Yes, you can, that's my point. Just write a CGI script that redirects to 
one of the above URLs, after having converted the URL accordingly.


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

You can do that now. Just make yourself a CGI script and register that.

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