- From: <piranna@gmail.com>
- Date: Tue, 17 Sep 2013 12:09:50 +0200
- To: "public-webapps@w3.org" <public-webapps@w3.org>
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 protocol on an <img> tag and it seems to works (at least on Chrome v28). Problem is, being a plain GET operation (or equivalent) it only fetch the file content, so it requires to point it to a web server that process the query (specially the '%s' argument) and return instead the correct resource. To prevent this requeriment, I have done some tests using a 'javascript:' URI so the handler would be procesed server-less (the 'GET equivalent operation' in this case is to exec the javascript code), but at least on Chrome v28 it doesn't get registered, but also it doesn't raise any exception or error. My proposition is to allow to use 'javascript:' URI protocols on the uri parameter of registerProtocolHandler, allowing this way to them being processed and executed server-less on client side. I know this would means some security thread (running arbitrary javascript code on ANY page that has a link or image with that scheme), so to put it at the same security level of doing a request to a regular web server, this code could be executed on a diferent process (something similar to how webworkers works), and from the point of view of the developer of this script the content returned by this 'GET equivalent operation' would be done by a document.write() operation, only that instead writting on the caller page document, it is fully written (probably also the HTTP headers if necesary) on an ad-hoc document that will be the one returned by this request. -- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
Received on Tuesday, 17 September 2013 10:10:38 UTC