Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Thu, 30 May 2013, chris cargile wrote: there seems to be a limitation that either registerProtocolHanlder() takes GET requests but not POST requests Since you are only ever sent a URL, this seems like the appropriate kind of request, no? On Thu, 30 May 2013, chris cargile wrote: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22022. I don't really understand the problem here. Can you elaborate? What problem are you trying to resolve? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
in case the associated thread of messages for this subject are not referenced by pipermail via this post's title, I wanted to link to them here-http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html. I'm writing to discuss/obtain clarification regarding a post that was intended to serve as a suggestion from me (which is filed in the w3c system, perhaps primarily aimed at identifying bugs) to avoid any loss of momentum and hopefully reach the relevant,target audience. In my w3c suggestion(/bug?) post I described - similar to as voiced in the older thread- that there seems to be a limitation that either registerProtocolHanlder() takes GET requests but not POST requests or perhaps Gmail --- as a UA seems to.. To properly route this, I hope you'll help me to understand whether using POST in conjunction with mailto:/gmail(-UA) is a w3c concern or a gmail-team concern, so I can begin helping shape the web with you! Thanks for helping,Chris
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
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 %2525s 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=1did=1a=1to=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=0to=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=mailtourl=; into what's really supported, which is: http://mail.google.com/mail/?compose=1view=cmfs=1to=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
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Sun, 11 Oct 2009 05:09:56 -0400, Ian Hickson i...@hixie.ch wrote: 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. O.K. 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 %2525s 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! Think of the longest email body you've ever sent. Think of the longest comma-separated cc, bcc, and To lists you've ever used. Think of the longest subject you've ever used. Think of all of that at once, properly percent-encoded in a mailto URI. Then, percent-encode that whole mailto URI. The length of the resulting string is an example of the length I'm talking about that should be supported as a worst case length-wise. 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. O.K. 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. O.K. 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. :) Yes, point taken on that. When all else fails though and you're the type that's so inclined to work around things, you might like it. 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=1did=1a=1to=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=0to=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=mailtourl=; into what's really supported, which is: http://mail.google.com/mail/?compose=1view=cmfs=1to=su=body=cc=bcc=;. However, it doesn't seem like many other sites
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
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=1did=1a=1to=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=0to=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. --
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Mon, 05 Oct 2009 07:27:08 -0400, Ian Hickson i...@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 %2525s 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=1did=1a=1to=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=;
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Sat, 19 Sep 2009 13:49:15 +0200, Michael A. Puls II shadow2...@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. 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? 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? 4. Whether to use POST instead of GET. That seems dangerous. Following a link should always use GET. [...] 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
2. The location of an icon like a favicon.ico file or png etc. This is actually a real privacy issue. The user agent would periodically fetch a remove favicon, which discloses the end user's ip. If any, such favicon would need to be made available offline immediately when installing the protocol handler, or a data uri could be used.
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Tue, 22 Sep 2009 09:54:12 -0400, João Eiras jo...@opera.com wrote: 2. The location of an icon like a favicon.ico file or png etc. This is actually a real privacy issue. The user agent would periodically fetch a remove favicon, which discloses the end user's ip. If you go to a site that uses registerProtocolHandler and you allow it to register the handler, you already trust that site and have already disclosed your ip to it. You'll disclose your ip to it again each time you visit the site. Now, if the site, which I obviously trust given the above, knows that my browser is fetching the favicon fresh now and then and can see my ip (and can even set a cookie when requesting the favicon), I think that's a non-issue. However... If any, such favicon would need to be made available offline immediately when installing the protocol handler O.K., that would be acceptable. And, the UA could allow the *user* to explicitly refetch the icon if they ever wanted to. The UA wouldn't even really have to allow a refetch as the user could just go back to the site and re-register then handler. -- Michael
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren ann...@opera.com wrote: On Sat, 19 Sep 2009 13:49:15 +0200, Michael A. Puls II shadow2...@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
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Tue, 22 Sep 2009 17:32:59 +0200, Michael A. Puls II shadow2...@gmail.com wrote: On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren ann...@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/
Re: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
On Tue, 22 Sep 2009 11:46:01 -0400, Anne van Kesteren ann...@opera.com wrote: On Tue, 22 Sep 2009 17:32:59 +0200, Michael A. Puls II shadow2...@gmail.com wrote: On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren ann...@opera.com wrote: 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. O.K., I see. Thank for clarifying. In those cases, a favicon will most likely be already known. But, take Opera's webmailproviders.ini for example. You have to manually specify the icon location. It's not discovered automatically through other means. If the user allowed registerProtocolHandler to add a webmail entry to the file, being able to say what icon to load would be great. But, even if a favicon (or other type of pic) can be discovered automatically, will the browser pick the right one? Maybe there's a specific file that should be used. Now, if every UA's protocol configuration is going to be plain jane text-only, then an icon for example isn't an issue. -- Michael
[whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
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.
2. The location of an icon like a favicon.ico file or png etc.
3. URI to a help page where the site explains how it makes uses of
registerProtocolHandler and gives help and support contacts etc.
4. Whether to use POST instead of GET.
For #1, if the UA knows this, it can automatically make sure the data goes
out to the server in the right encoding.
For #2, if the UA knows this, it can automatically provide the desired
icon in its UI next to each entry in its protocol configuration dialog,
for example.
For #3, if the UA knows this, it can automatically provide a site support
link in its configuration dialog.
For #4, if the site would rather (or can only) accept POST data (to
support longer data for example), then the UA can automatically oblige.
With that said, it'd be great if registerProtocolHandler supported a 4th
argument that was an object of informative things.
For example, here are some things that could be supported:
var info = {
accept-charset : koi8-r,
icon : http://example.org/some_dir/favicon.ico;,
help : http://example.org/support/protocol_handling.html;,
requestMethod : POST
};
navigator.registerProtocolHandler(protocol,
http://example.org/?uri=%s;, title, info);
Or, if you'd rather not use an object and just have more arguments:
navigator.registerProtocolHandler(
protocol,
http://example.org/?uri=%s;,
title,
koi8-r,
http://example.org/some_dir/favicon.ico;,
http://example.org/support/protocol_handling.html;,
post
);
Now, if you noticed, I used automatically above. This is because I think
it would not be ideal to have a site register itself to handle a protocol
only to have it not work by default and have the user find some page on
the site that tells them how to manually configure options in each browser
just to get things working.
To give an example, Opera supports registering certain webmails with
mailto. You currently have to edit an ini file to add more than the
default and Opera doesn't support registerProtocolHandler yet, but what
Opera does support is specifying an icon URI that gets used in the UI.
Opera also only supports GET at the moment and only supports emitting
utf-8, but there are a few sites where POST and a different output
encoding are desired by the webmail. For example, mail.ru would rather
have POST being used and they only accepted koi8-r (and Windows-1251 as an
option) up until recently.
With that said, if Opera supported registerProtocolHandler to add a
protocol handler (mailto for example), having the site be able to specify
an icon could be usable by Opera and other UAs.
If Opera ever supports using POST or emitting a different encoding, having
the site say so would help so the user doesn't have to manually find out
and configure all this stuff.
Now, Firefox supports registerProtocolHandler for adding handlers now.
But, you can't configure post/get or icons etc. either. But, if you could,
it'd be great to have the site say what to use. (You also have to use an
about:config override to make handler work on any domain)
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. 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.
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=1did=1a=1to=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=0to=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,
