Re: Allow javascript: URIs for registerProtocolHandler

On Wed, 18 Sep 2013, Anne van Kesteren wrote:
> On Tue, Sep 17, 2013 at 4:34 PM, piranna@gmail.com <piranna@gmail.com> wrote:
> > Really :-) I though the same, but since its a "GET equivalent 
> > operation" just like XHR and in fact Google Charts creates on-demand 
> > graphics based on the data on the URL query, so why not? So I created 
> > a custom fake protocol, set it inside the <img> tag and after 
> > registering and removing the fake protocol several times, I saw it 
> > only showed the image using the fake protocol when it was registered 
> > :-)
> 
> """ This section does not define how the pages registered by these 
> methods are used, beyond the requirements on how to process the url 
> value (see above). To some extent, the processing model for navigating 
> across documents defines some cases where these methods are relevant, 
> but in general UAs may use this information wherever they would 
> otherwise consider handing content to native plugins or helper 
> applications. """
> 
> Ian, was it ever the intent that these methods affect the way Fetch 
> works? Either way, this could use some tightening up as the current 
> language is quite vague. I think we should only let them affect the 
> navigate algorithm. Either way, we should clarify where the URL 
> translation happens as that will affect Service Workers (latest name of 
> Navigation Controller).

An interesting question.

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2663

Safari doesn't support navigator.registerProtocolHandler().
I couldn't test IE but research suggests it doesn't support it.
Chrome supports it at the Fetch level, as a redirect.
Firefox supports it at the Navigation level, as a redirect.

Chrome's support is certainly attractive. The test above uses a custom 
protocol (web+twocats:) to register a URL that shows a picture, which can 
then be used in an <img>. I tried using XMLHttpRequest, and it didn't 
work, but only because "Cross origin requests are only supported for 
HTTP", which seems like something we could extend, especially in the case 
of registered protocol handlers that "expand" to HTTP URLs.

There are certainly use cases for supporting these in <img> and XHR. For 
example, a TIFF -> PNG convertor could be registered for a content 
handler, in theory, enabling TIFF images to be used in <img>. A site could 
allow itself to be themed by defining a "protocol" that was used to expose 
images and style sheets that it would then link to using this protocol. A 
site could expose itself as a cloud storage provider, and then files could 
be actually downloaded from that provider using XHR, without the client 
site knowing which provider was being used. There's plenty of interesting 
possibilities if you do this at the fetch level.

That's not to say that it'd be especially usable, as an API. If we really 
wanted to support these use cases, we might be better off doing it more 
explicitly, at the JavaScript level, providing ways for sites to spin up 
background cross-origin workers on demand, providing sites with a 
full-service API.

I don't really see any security issues with doing it at the fetch level; 
security issues would be the prime suspect for a rationale for doing 
things only for navigation. For example, we've limited javascript: now to 
only being done for navigation. (As a side note, javascript: is a 
non-starter for register*Handler(), because it would let script get run in 
the context of the source of the link. So the original topic of this 
thread is somewhat moot.)

Anyway. I think we should probably put this logic into Fetch, really.

As far as Service Workers go, I would hope the service worker for the 
domain of the source of the URL (as opposed to the domain of the 
registration) would never see the URL at all, since it'd be cross-origin.


On Wed, 18 Sep 2013, piranna@gmail.com wrote:
>
> I find the fact of being able to use custom protocols on <img> and 
> <script> tags a cool feature instead of a bug, so I would not let them 
> only to be used just for navigation purposes. Also, after reading about 
> Service Workers, I think that a combination of both can lead to really 
> interesting things. At least for my own personal use case (web surfing 
> on a WebRTC DataChannels-based P2P network, translating the request 
> using a custom protocol to the real location of the resources) would be 
> the best solution, and also would lead to other interesting use cases 
> (web servers inside the browsers... :-P ).

On Wed, 18 Sep 2013, Anne van Kesteren wrote:
> 
> Maybe. We'd lose the symmetry with registerContentHandler() unless we 
> move its redirect-like logic to fetch as well, aside from the security 
> implications. And "cool feature" is not a solid enough use case I think 
> for the complexity it brings.

The complexity is pretty low, no?

(I agree that both kinds of registrations should work the same.)


On Wed, 18 Sep 2013, piranna@gmail.com wrote:
> 
> This would need more discussion. It would be useful to allow 
> registerContentHandler() also to be used inside <img> tags, but also I 
> don't think too much people will be creating their own file formats that 
> would require registerContentHandler() in the same way they would create 
> their own custom protocols, so maybe loose the symmetry here makes 
> sense...
>
> [...] By "cool feature" I means that it wide open the usage 
> posibilities, for example someone would create a 'wiki:' protocol to add 
> links to Wikipedia and when when used on a <img> tag like 
> 'wiki:images/dog.png' 'would insert images directly, or a 'youtube:' 
> protocol to insert videos on a <video> tag. This would require to have 
> registered the protocol, obviously, but the same happens if they are set 
> on a link that people can click and surf...

This is primarily useful for site-agnostic solutions, e.g. 
"dictionary:depreciate" for embedding a dictionary definition of 
"depreciate" from whatever the user's preferred dictionary is, rather than 
"oxford:depreciate" which might as well be written as a URL to the Oxford 
Dictionary site directly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 27 November 2013 23:44:00 UTC