Re: Allow javascript: URIs for registerProtocolHandler

2013-12-13 Thread Anne van Kesteren
On Fri, Dec 13, 2013 at 2:54 PM, Anne van Kesteren wrote: > A problem would be that > > > > is no longer safe as it could execute a network request if the MIME > type was text/vcard or some such. I also filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091 to further consider this. -- ht

Re: Allow javascript: URIs for registerProtocolHandler

2013-12-13 Thread Anne van Kesteren
On Wed, Nov 27, 2013 at 11:43 PM, Ian Hickson wrote: > 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

Re: Allow javascript: URIs for registerProtocolHandler

2013-11-27 Thread Ian Hickson
On Wed, 18 Sep 2013, Anne van Kesteren wrote: > On Tue, Sep 17, 2013 at 4:34 PM, pira...@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, s

Re: Allow javascript: URIs for registerProtocolHandler

2013-09-18 Thread pira...@gmail.com
> Maybe. We'd lose the symmetry with registerContentHandler() unless we > move its redirect-like logic to fetch as well, aside from the security > implications. This would need more discussion. It would be useful to allow registerContentHandler() also to be used inside tags, but also I don't thin

Re: Allow javascript: URIs for registerProtocolHandler

2013-09-18 Thread Anne van Kesteren
On Wed, Sep 18, 2013 at 8:42 AM, pira...@gmail.com wrote: > I find the fact of being able to use custom protocols on and >

Re: Allow javascript: URIs for registerProtocolHandler

2013-09-18 Thread pira...@gmail.com
> 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 a

Re: Allow javascript: URIs for registerProtocolHandler

2013-09-18 Thread Anne van Kesteren
On Tue, Sep 17, 2013 at 4:34 PM, pira...@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

Re: Allow javascript: URIs for registerProtocolHandler

2013-09-17 Thread pira...@gmail.com
> > When using registerProtocolHandler method to register a custom > > protocol, according to the spec it is required that the uri parameter > > allow to do a GET operation or their equivalent (so maybe it would be > > used with ftp instead of http URIs, for example). I have done some > > tests set

Re: Allow javascript: URIs for registerProtocolHandler

2013-09-17 Thread Brendan Eich
Anne van Kesteren September 17, 2013 12:25 PM Really? I thought registerProtocolHandler() was only a hook for navigation. As an aside, the plan of record is to limit javascript URLs to navigation. Unless they result in undefined, in which case they evaluate against the

Re: Allow javascript: URIs for registerProtocolHandler

2013-09-17 Thread Anne van Kesteren
On Tue, Sep 17, 2013 at 6:09 AM, pira...@gmail.com wrote: > When using registerProtocolHandler method to register a custom > protocol, according to the spec it is required that the uri parameter > allow to do a GET operation or their equivalent (so maybe it would be > used with ftp instead of http

Allow javascript: URIs for registerProtocolHandler

2013-09-17 Thread pira...@gmail.com
When using registerProtocolHandler method to register a custom protocol, according to the spec it is required that the uri parameter allow to do a GET operation or their equivalent (so maybe it would be used with ftp instead of http URIs, for example). I have done some tests setting this custom pro