W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2006

[whatwg] Registering protocol handlers

From: Christian Biesinger <cbiesinger@web.de>
Date: Fri, 21 Apr 2006 21:49:45 +0200
Message-ID: <44493759.5030807@web.de>
Ian Hickson wrote:
> That's not a normative conformance statement, it's a statement of fact. 
> The normative conformance statement that results in this statement of fact 
> being true is the sentence immediately following it: "User agents must 
> compare the given values only to the MIME type/subtype parts of content 
> types, not to the complete type including parameters."
> 
> I've clarified this (hopefully) by reversing the order of the sentences.

Yeah, this order seems clearer to me, thanks.

> Per the spec, the methods do not check the syntactic validity of their 
> arguments except for two things: The URI not having a %s, and the scheme 
> or content types being "privileged" (http:, text/html, etc).

That's really of no help at all, since at some point the validity must 
be checked. But I assume this means that syntactic invalidity means that 
the call to register*Handler returns normally but does nothing.

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.

[escaping]
> I've fixed these issues. Thanks. Let me know if there is still a problem.

Looks fine. I want to note that this prescribes using uppercase 
characters for the escaping, which is more strict than RFC 2396. Are 
there any browsers that currently use lowercase characters for escaping?

>> - The section "4.10.2.1. Security and privacy concerns [...]" has an
>> informative-sounding heading but does in fact seem to have normative
>> statements like "User agents must never send username or password information
>> in the URIs that are escaped and included sent to the handler sites."
> 
> Non-normative sections are explicitly marked. However, if you can think of 
> a better section title I'm open to suggestions.

It turns out that I'd be happier if you moved the normative parts into 
the section before and made this one informative :) Most of it is 
informative, anyway.

> The answer to all these questions is basically the same:
> 
> What would you want the spec to say?

Certainly not something that amounts to "now you can feel free to forget 
everything I said above". For a start, you could say something like:


   This specification does not require a particular UI, or how
   a browser should select a handler for a content type or protocol.
   Therefore, the exact handling of calls to these functions is not
   specified. However, if the browser ends up using the handler
   registered by the website, it must follow the rules described
   above.

With that, you could probably strike the "This section does not define 
how the pages registered by these methods are used." sentence too.

> I can't require a particular UI. It's the same as the part of the spec 
> that defines what happens when you click a link -- to a large extent, it's 
> up to the UA. It could save the document, render it in a new tab, in a new 
> window, e-mail the link to someone, copy the link to the clipboard, or 
> whatever. It's not up to the spec to define that. The spec just defines 
> the API; how that is represented in the UA is up to the UA vendor.

True... and the two issues that refer to this kind of thing are probably 
not all that important anyway. (Although it does sound like your todo 
block in section 3.1 contradicts your statement here a bit)


Oh, something else. There are, in my opinion, a lot of issues with 
registering a handler for a content type, as opposed to a protocol.

Some of them being:
- The request that led to this content may be not idempotent
- The request may require POST data
- 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
- Obviously also the leaking intranet URI issue you mention
- The browser already has partial content, or maybe the full content 
(for a short file), by the time it sees the content type (e.g. network 
I/O on a background thread, content dispatch on the main thread, and a 
short file). It requires the browser to throw away the data it has, 
which is sort of ugly, especially if it is impossible to get it again 
(see earlier points)

The browser can not know for all of them if that is the case. The user 
may not know either. This leads to a kind of ugly situation that it may 
be impossible for the user to actually view the content. The spec does 
not address these issues at all.

It turns out that most of these issues could be addressed by 
implementing the content handler by a file upload to the registered URI. 
What do you think about that? It addresses all the issues, but has a 
major downside, of course: It makes it really easy to leak data to a 
third party (in an automatic way even: register a handler for a certain 
type, then do 
location.href="http://intranet/some_confidential_word_file.doc")

I can see that this may not be the best solution either. But, given the 
issues that your solution has, I'd hate to see a WhatWG spec suggesting it.

Oh, there's also 
http://groups.google.com/group/mozilla.dev.platform/msg/3f9d1a67780944df 
which was posted while I was writing this email.

-biesi
-------------- 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/20060421/0dc9935e/attachment.bin>
Received on Friday, 21 April 2006 12:49:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:46 UTC