[whatwg] Registering protocol handlers

[Ian Hickson]

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:

   <button onclick="
     navigater.registerContentHandler('http://www.example.com/é', ...);
   "/>

...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)

Added.


> > > 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 
> account?

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 
change.)


> 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 
near-impossible.


> 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 
> you?

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 
browser-sniff.

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.   `._.-(,_..'--(,_..'`-.;.'