- From: Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de>
- Date: Fri, 10 Apr 2015 14:06:52 +0000
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- CC: "public-secondscreen@w3.org" <public-secondscreen@w3.org>
Thx Anssi for feedback I will open a new GH issue for URL schemes supported by the APIs and discuss related issues like limitations, security considerations, performance, etc. The file:// protocol could be also relevant for non-hosted content for example for packaged web apps like W3C Widgets. Louay > -----Original Message----- > From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com] > Sent: Freitag, 10. April 2015 15:57 > To: Bassbouss, Louay > Cc: public-secondscreen@w3.org > Subject: Re: Use URL data: scheme in presentationUrl > > Hi Louay, All, > > > On 10 Apr 2015, at 11:25, Bassbouss, Louay > <louay.bassbouss@fokus.fraunhofer.de> wrote: > > > > What do you thing about using “data:” scheme in presentationUrls e.g. > “data:text/html;charset=utf8;base64,<base64 encoded inline html content > goes here>”? Example: > > > > var presentationUrl = > > > “data:text/html;charset=utf8;base64,PGh0bWw+DQo8aGVhZD48dGl0bGU+ > VGVzdDwvdGl0bGU+PC9oZWFkPg0KPGJvZHk+DQo8aDE+UHJlc2VudGF0aW9 > uIEFQSSB3aXRoIGRhdGE6IHNjaGVtZTwvaDE+DQo8L2JvZHk+DQo8L2h0bWw > +”; > > var session = navigator.presentation.startSession(presentationUrl ); > > > > The following screenshot shows the output If you open the > presentationUrl in browser (tested in chrome); > > That is a good question. > > Whatever we decide, we should specify the expected behaviour in order to > allow the implementations to interoperate after we've figured out whether > the API should work with data URIs. > > I think there may be a disagreement among implementers whether data > URIs are same-origin depending on where they're used (Worker, iframe, > img, open()...). I think the closest existing API to startSession() where data > URIs can be used is open(). > > I think the primary motivation for using data URIs has been performance. > HTTP/1.x has known limitations in loading multiple resources concurrently, so > inlining all the resources has improved the performance. Another use case I > can think of is to be able to provide a single file that contains all the resources > without the need to package multiple files together. > > The base64 encoding is required for binary data only, so in this API we could > use text/html to make the markup human-readable: > > startSession('data:text/html,<!DOCTYPE > html><html><body><p>Test</p></body></html>') > > Louay, All - I think you should investigate this further and come up with a > recommendation on how to proceed i.e. whether data URIs should be > allowed or not, and how to spec that. Please feel free to open a GH issue for > tracking this. > > Thanks, > > -Anssi (WG chair)
Received on Friday, 10 April 2015 14:07:29 UTC