[whatwg] Registering protocol handlers
ian at hixie.ch
Mon Apr 24 00:57:36 PDT 2006
On Sat, 22 Apr 2006, Christian Biesinger wrote:
> > They can't be checked at the registration point, because the URI might
> > become valid before it is used, and because the networking library
> > might not be able to tell if the URI is valid without fetching it.
> > (It's also not really clear where you draw the line of an "invalid"
> > URI -- is http://192.0.2.812/ an invalid URI?)
> Oh, our interpretation of "valid" is different, obviously :) The way I
> used it an invalid URI would never become valid. I meant it
> syntactically only.
So, like, the address in the following HTML:
...would be invalid? Or not? That changed when the IRI spec came out. I'm
not sure you can guarentee that a URI will always be invalid.
> Anyway, I wonder if it's worth mentioning that malformed URIs should
> never cause an exception to be thrown? (other than lack of %s of course)
> > > BTW... shouldn't sites have the possibility to unregister
> > > themselves? I as a user would expect a site that has a "register me"
> > > button to also have an "unregister me" button.
> > I would presume the UA would provide this option, not the page.
> > (Similarly, you don't have a Web API to remove a search engine, only
> > to add one.)
> Sure, the UA should have that as well. But it feels to me that the page
> should also have it. This API is more likely than the search engine case
> to register pages that require having an account (e.g. subscribe to a
> feed, import a .ics file, send an email (mailto:foo at bar)). Wouldn't it
> be nice if the page could unregister itself when the user deletes their
I don't know, would it? I don't see the use case. Why would, e.g., Flickr,
ever unregister itself as an image/x-flickr handler? (The only theoretical
case I can see, namely the site changing its server location, seems like a
bad reason -- you should always support the old location, good URIs don't
> Hm... actually it's possible that we have differing ideas of how the UI
> will look. I am imagining that there will be an option for the user to
> always open that protocol/content type with the specified URL. If this
> is done during registration, where would you as a user expect to
> unregister the URL again? Where you registered it, I would say.
I think that would be a very dangerous option. But in any case, consider
the case for a download today -- you can set the default to always be a
particular app when you download a file, so how do you change the default?
IMHO it would be in the same place.
> But, I don't feel strongly on this point. If this doesn't convince you,
> I'm fine with that :)
I think we should wait until we have more experience before adding the
unregister feature. Adding features is reasonably easy. Removing them is
> I do suspect that this will lead to inconsistent UI. Some files will go
> to the registered URL, some to the pre-existing handler (local app or
> something). The user may have no idea why.
The same could be said today for clicking on a link. I'm all for making
this better, but I don't see what the spec can do to help.
> > This seems equivalent to what is currently in the spec -- the spec
> > already says that when the UA uses the given URI, it must do so in a
> > particular way. I've added some minor text to reference that more
> > explicitly in the paragraph you mention.
> To me, "User agents may do whatever they like" means that there are no
> restrictions. It sounds to me like they can ignore everything that was
> said before. I guess leave this as-is if you don't think people will
> read it that way.
Clearly people will, if you did. :-)
I've changed it to:
User agents may, within the constraints described in this
seciton, do whatever they like [...]
> > > - The request may have required certain cookies
> > > - The request may have required certain authentication headers
> > > - The request may only be possible from certain IP ranges
> > In other words, the content might be privileged -- in which case you
> > definitely don't want to send it to a remote site!
> No, you may still want to send it to a remote site. Consider this: A
> university's information system may allow exporting a student's courses
> for a semester as an ICS file. A user may well not mind sending that ics
> file to Google Calendar, but accessing that export functionality does
> require authentication of course.
I think for this case the university should either offer a "private" URI
that can be forwarded to the remote site (much like how Google Calendar
has a "private URI" for your ICS file), or the user should download the
file, go to the other site, and upload it.
> > Leaking intranet URIs is a lot less dangerous than leaking intranet
> > _content_, though.
> Yeah. That's true.
> > No, it doesn't require anything. The spec doesn't say when you use
> > this --
> Convenient, isn't it?
> > in particular, it doesn't say you should use these options for the
> > result of non-GET or authenticated requests. It even says that maybe
> > you _shouldn't_ use it for authenticated requests, and I've now added
> > a sentence that says you musn't use it for non-GET resources.
> Again, I fear this will lead to inconsistent UI. That you don't say when
> it should be used is also not ideal, but I guess unavoidable as you
> don't want to require a certain UI.
I don't see how we can require a certain UI. User Interface is how
browsers differentiate from each other.
> Let me ask you: Does a spec with this many unspecified details satisfy
Yes, I wouldn't have written it otherwise. :-) This is not a UI spec --
this is a spec that is to ensure one thing and one thing only, namely that
the same basic feature can be offered for any browser without having to
Specs don't say how, e.g., <select> elements should work, other than the
fact that they should offer certain options. Whether it's control-click or
command-click or whether it's a drop down or a list or whether it's a
pop-up, is all up to the UA. You can't require a particular UI, because
some applications (e.g. EmacsSpeak) have radically different UIs than
others (e.g. Opera on a cell phone).
> > The main use cases I see here are for feeds, and for those you
> > definitely want to send the URI. Same with, e.g., an iCalendar feed.
> Maybe. The iCalendar file in question may not be something that changes
> though. It seems to me like this is useful only for very few use cases,
> limited basically to feeds.
> I'm not happy with registerContentHandler at all.
I'm not sure how to address your issues. What text would you like to see
be added to the spec?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg