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

[Anne van Kesteren]

On Tue, 22 Sep 2009 17:32:59 +0200, Michael A. Puls II  
<shadow2531 at gmail.com> wrote:
> On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> The IRI specification dictates UTF-8 already.
>
> But sites might not follow it.

Then they will need to be updated if they want to work with  
registerProtocolHandler and pretty much any form of requests to their URL  
space they do not control themselves (i.e. is not initiated by following  
some HTML link on their site). Even XMLHttpRequest forces UTF-8.


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

I have a PNG called favicon.ico on my site, but what I meant is that the  
user has likely visited the site already so a favicon of some sorts will  
be known. Also, this only matters when registering for the handler and  
having icon support there might actually make phishing easier as the user  
would recognize the icon and maybe ignore the text.


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

What can possibly go wrong that the site cannot fix with a redirect of  
some sorts?


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

I don't quite see how you envision this to work. I suppose at some point  
unknown protocols could be made to work in <form>. Dunno though.


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

It is robust. Adding lots of complexity is likely to make it less so.


-- 
Anne van Kesteren
http://annevankesteren.nl/