- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 11 Oct 2009 09:09:56 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 11 October 2009 02:09:56 UTC