[whatwg] registerProtocolHandler - allow site to specify more info and do custom handling
Ian Hickson
ian at hixie.ch
Sun Oct 11 02:09:56 PDT 2009
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list