[whatwg] Registering protocol handlers

[Christian Biesinger]

Ian Hickson 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.

Interesting, Mozilla doesn't consider that URI invalid :)

An example of an invalid URI would be "http://a b" (space in the hostname)

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)

> The caller cannot determine that the URI is invalid from calling this API, 
> correct. What the UA actually does is up to the UA.

OK, I'll accept that, I guess.

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

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.

But, I don't feel strongly on this point. If this doesn't convince you, 
I'm fine with that :)

> There are no browsers that do anything for this API so far. I specified 
> uppercase so that servers would not be surprised one day if they hardcoded 
> uppercase and later found a client using lowercase. Anything we can do to 
> make the server side easier is a win.

Well, what I meant was that browsers have existing functions to escape 
URIs, and they would likely reuse that for implementing this feature, so 
if that currently uses lowercase, implementing this would require 
additional work to use uppercase instead.

But this is not an important issue either.

> All but one of the paragraphs has at least one normative conformance 
> criteria, so most of it is not informative. I'm not sure how to address 
> your concern here.

I think I figured out what still bothers me there. None of the 
paragraphs say what should happen when the case happens. But I guess 
that's because you don't want to require a certain UI.

That does seem to be a major problem of this part of the spec to me. 
Many issues can't be addressed because you can't require a certain UI. 
Oh well.

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.

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

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

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

Let me ask you: Does a spec with this many unspecified details satisfy you?

[file upload rather than sending the URI]
> It seems very dangerous.

Yeah...

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

(registerProtocolHandler() seems fine, though)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4762 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060422/d2dd9fc5/attachment-0001.bin>