- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Sun, 11 Oct 2009 16:23:21 -0400
On Sun, 11 Oct 2009 05:09:56 -0400, Ian Hickson <ian at 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
Received on Sunday, 11 October 2009 13:23:21 UTC