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 "%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!
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=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.
I've actually done this *a lot*. The main issue I run into though is that
the redirection across domains can fail to autolog you into the webmail if
you have 3rd party cookies blocked, depending on the browser.
With that said though, I'll just leave it at that and perhaps revisit this
later. This thread should at least be very useful for webmail vendors to
see what's expected of them and what they have to work with. It will also
show what browser vendors have to work with.
Thanks
--
Michael
