On 4/20/2011 2:11 AM, Lachlan Hunt wrote:
On 2011-04-19 19:33, Ian Hickson wrote:
On Tue, 12 Apr 2011, Lachlan Hunt wrote:
We are investigating registerProtocolHandler and have been discussing
the need for a blacklist of protocols to forbid.
[...]
We'd like to know if we've missed any important schemes that must be
blocked, and we think it might be useful if the spec listed most of
those, except for the vendor specific schemes, which should probably be
left up to each vendor to worry about.
I haven't updated the spec yet, but it strikes me that maybe what we
should do instead is have a whitelist of protocols we definitely want to
allow (e.g. mailto:), and define a common prefix for protocols that are
used with this feature, in a similar way to how with XHR we've added
Sec-*
as a list of headers _not_ to support.
Other protocols we should probably also whitelist:
irc, sms, smsto, tel.
I'm also curious how we could handle ISBN URNs, like:
urn:isbn:0-395-36341-1
That would be useful to have a web service that could look up the ISBN
and direct users to information about the book, or to an online store.
As currently specified, services have to register a handler for "urn",
even if they only handle ISBN URNs. The other alternative would be to
mint a new web+isbn scheme, which seems suboptimal.
Maybe registerProtocolHandler() could take a function as an extra
argument to let the application determine whether it wishes to handle
the protocol event, internally using e.preventDefault(),
e.stopPropagation(), or something similar to indicate that it has
successfully handled the case, and pass the buck to let other protocol
handlers be checked in order of user preference otherwise.
So e.g. we could whitelist any protocol starting with "web+" and then
register that as a common extension point for people inventing protocols
for use with this feature, so that people writing OS-native apps would
know that if they used a protocol with that prefix it's something
that any
web site could try to take over.
That seems reasonable.
Now that it seems there is momentum on resolving the URN and custom
(pseudo-)namespacing issue (I think "x-" might be nice to continue the
tradition, though "web" seems fine also if real namespaces will not be
used), can we please put back on the table the ideas of:
1) adding to <a/> an attribute "uris" (for trying alternatives first,
with greater precedence than "href")
2) adding to <a/> an attribute "fallbackURIs" (for lesser precedence
than "href", e.g., so a browser might expose these URIs only when the
link was right-clicked)
3) adding an event to listen for the user refusing or the browser not
supporting a protocol (even if this can be done with try-catches).
...so that people can actually begin experimenting with
registerProtocolHandler() rather than expecting content authors to make
links which may lead to nowhere for some of their users?
Brett
