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/