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

[Michael A. Puls II]

On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren <annevk at opera.com>  
wrote:

> On Sat, 19 Sep 2009 13:49:15 +0200, Michael A. Puls II  
> <shadow2531 at gmail.com> 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.
>
> The IRI specification dictates UTF-8 already.

But sites might not follow it.

>> 2. The location of an icon like a favicon.ico file or png etc.
>
> Is this not already known? Or is there no same-origin restriction on  
> these methods?

Do you mean, is the location known like favicon.ico at the root of the  
site? It's not always in that spot. And, if it's not a favicon, but a png  
for example, it could be anywhere on the site.

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

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

Now, the user could go hunting through the site to find that page, but the  
link is much more user-friendly.

>> 4. Whether to use "POST" instead of GET.
>
> That seems dangerous. Following a link should always use GET.

But, I don't think it's necessarily "following a link" in the normal  
sense. It's launching a trusted web-based application, where POST could be  
used to support longer data.

Sure, it's great to look at the query to see what's being submitted (if  
it's in a format that you know how to decode).

By default though, the handler only works on pages for the site that  
registered the handler, so it'd be like just using a form POST right on  
the site.

>> [...]
>>
>> 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.
>
> I don't see why existing sites would not update what they accept to make  
> registerProtocolHandler work.

I do. Sites can be a pain. :)

> And if user agents want to support sites that do not support  
> registerProtocolHandler that is their business I think and not an  
> necessarily an issue for the feature.

Sure, but if registerProtocolHandler is robust, users don't have to wait  
around for browsers to do that. registerProtcolHandler would be  
self-sufficient.

I think it's important to have robust tools to allow users to make things  
work when either the site or the browser or both are of no help. But, my  
main point in all this is if the UA has more than just a plain UI, it  
could make use of more info given by registerProtocolHandler to make  
things nicer.

In short though, I think registerProtocolHandler is too simple. Maybe  
that's intentional and browses are encouraged to support some other more  
advanced function like  
window.ff|ie|opera|safari|chrome_advancedRegisterProtocolHandler, but why  
do that when registerProtocolHandler could?

But, understood if you don't share my enthusiasm.

-- 
Michael