Re: Streams and Blobs

[Glenn Maynard]

On Fri, Mar 8, 2013 at 10:40 PM, Jonas Sicking  wrote:

> > But what about the issues I mentioned (you snipped them)?  We would be
> > introducing overlap between XHR and every consumer of URLs
> > (HTMLImageElement, HTMLVideoElement, CSS loads, CSS subresources, other
> > XHRs), which could each mean all kinds of potential script-visible
> interop
> > subtleties.
>
> As long as we define the order between when data is going into the
> Stream, and when the events are fired on the XHR object, I think that
> takes care of these issues.
>

The isn't just between XHR and Stream, it's between XHR/Stream and the API
receiving the data, such as HTMLImageElement and everything else that takes
a URL.

For example, EventSource queues tasks to fire onmessage in the remote event
task source.  This means that the order of XHR events and EventSource
onmessage events will be unspecified.  Some browsers might always send
those onmessage events before sending XHR events, which guarantees that
onmessage will never be received after XHR's onload.  Other browsers might
prioritize XHR's tasks, causing XHR's onload to happen first, so it
wouldn't have that guarantee.

(I have no idea how many cases like this exist, and that's what worries me.)

This problem doesn't exist with the finish-and-return approach, since
Stream itself doesn't have any events.


> - What happens if you do a sync XHR?  It would block forever, since you'll
> > never see the Stream in time to hook it up to a consumer.  You don't
> want to
> > just disallow this, since then you can't set up streams synchronously at
> > all.  With the "XHR finishes immediately" model, this is straightforward:
> > XHR returns as soon as the headers are finished, giving you the Stream
> to do
> > whatever you need with.
>
> Sync XHR already can't use .responseType, so there is no way for sync
> XHR to return a Stream object. We should put the same restriction on
> Sync XHR accepting a Stream as a request body.
>

What?  Of course sync XHR can use responseType.
https://zewt.org/~glenn/sync-responsetype.html

And again, you don't want to just disallow this, or you couldn't create
streams synchronously in workers.  We can create a Blob synchronously, then
read data out of the blob synchronously; we should also be able to create a
Stream synchronously, and parse data from it synchronously.

 > - What if you create an async XHR, then hook it up to a sync XHR?  Async
> XHR
> > only does work during the event loop, so this would deadlock (the async
> XHR
> > would never run to feed data to the sync one).
>
> Same as above.
>

It's not the same.  It's an async XHR returning a stream, and a plain
responseType="" sync XHR.

var client = new XMLHttpRequest();
client.responseType = "stream";
client.open("GET", url);
client.send();
client.onsomething = function() { // on whatever event means the Stream is
available
var sync = new XMLHttpRequest();
var url2 = URL.createObjectURL(client.response);
sync.open("GET", url2, false);
sync.send();
};

Any future synchronous worker APIs that could fetch data from a URL would
have the same problem with this design (there aren't any others yet that I
know of).

 > - You could set up an async XHR in one worker, then read it synchronously
> > with XHR in another worker.  This means the first worker could block the
> > second worker at will, eg. by running a blocking operation during an
> > onprogress event, to prevent returning to the event loop.  I'm sure we
> don't
> > want to allow that (at least without careful thought, eg. the
> "synchronous
> > messaging" idea).
>
> This is a good point. We probably shouldn't allow sync XHR in workers
> either to accept or produce Stream objects.
>

Now you can't stream synchronously, and now XHR suddenly cares about
whether an object URL comes from a Stream instead of being
protocol-agnostic (meaning black-box APIs that take a URL won't working
with them either).  This is adding weird restrictions to work around
problems with the design.

> With the supply-the-stream-and-it's-done model, XHR follows the same model
> > it normally does: you start a request, XHR does some work, and onload is
> > fired once the result is ready for you to use.
>
> This is not correct. All of .response, .responseText and .responseXML
> are often available much before that.
>

Nope.  The only time any of these is available (per spec) before the DONE
state is in responseType = "text", making that the exception.  All the rest
are only available in DONE.  The most common pattern with XHR is to call
send(), then wait for onload (or one of the other redundant events fired at
that time), which this approach follows.

> With the runs-for-the-duration-of-the-stream model, when is the .response
> > available?
>
> Ideally as soon as .send() is called. If that causes problem then
> maybe as soon as we enter readystate 3.
>

You need to know the MIME type to create a Stream, so you can't create it
until you've received headers.  Th

Re: security model of Web Components, etc. - joint work with WebAppSec?

[Arthur Barstow]

[ Apology for top-posting and continuing the cross-posting ]

Hi Brad,

Thanks, yes earlier security review and feedback would be good.

My preference is to use public-webapps (solely) for all discussions 
related to Web Components (WC).


Re discussing security and WC f2f, I added a joint meeting between these 
two groups as a potential agenda topic for WebApps' April 25-26 f2f 
meeting [1] but I did not allocate a specific day+time slot because it 
could be a bit premature right now. That said, if you, or Dimitri, or 
other WC people have a specific day+time you would prefer, please speak 
up and note we intend to meet all day on the 25th but only until noon on 
the 26th. (Of course we can cancel the joint meeting if it turns out 
there is no need to meet.)


-Thanks, ArtB

[1] 


On 3/8/13 6:56 PM, ext Hill, Brad wrote:


WebApps WG,

I have been following with interest (though with less time to give it 
the attention I wish) the emergence of Web Components and related 
specifications. (HTML Templates, Shadow DOM, etc.)


I wonder if it would be a good time to start discussing the security 
model jointly with the WebAppSec WG, both on list, and possibly at the 
upcoming F2F in April?


One of our goals in WebAppSec is that a mashup web of re-usable and 
composable pieces be possible to do securely. An example anti-pattern 
in this area is the widely deployed 

Re: Persistent Storage vs. Database

[Andrew Fedoniouk]

On Fri, Mar 8, 2013 at 8:16 PM, Jonas Sicking  wrote:
> On Fri, Mar 8, 2013 at 2:27 PM, Andrew Fedoniouk
>  wrote:
>> On Fri, Mar 8, 2013 at 11:30 AM, Kyle Huey  wrote:
>>> On Fri, Mar 8, 2013 at 11:02 AM, Andrew Fedoniouk
>>>  wrote:

 On Thu, Mar 7, 2013 at 10:36 PM, Kyle Huey  wrote:
 > On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk
 >  wrote:
 >
 >> At least it is easier than http://www.w3.org/TR/IndexedDB/ :)
 >
 >
 > Easier doesn't necessarily mean better.  LocalStorage is certainly
 > easier to
 > use than any async storage system ;-)
 >

 At least my implementation does not use any events. Proposed
 system of events in IndexedDB is the antipattern indeed. Exactly for
 the same reasons as finalizer *events* you've mentioned above - there
 is no guarantee that all events will be delivered to the code awaiting
 and relaying on them.
>>>
>>>
>>> That's not true at all.  If you don't understand the difference between
>>> finalizers and events you're not going to be able to make a very informed
>>> criticism of IndexedDB.
>>>
>>
>> I would appreciate if you will define term `event`. After that we can discuss
>> it further.
>
> https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-event

Thanks, but these are DOM events. How they are related to DB events or
whatever they are named?  What does it mean bubbling/capturing for them?


>
>> As of common practice there are two types so called outbound calls:
>> 1. Synchronous *callbacks* that are not strictly speaking events - just 
>> function
>>references: "after/before-doing-this-call-that". 'finalized' is
>> that kind of callback.
>> 2. Events - these are objects and event dispatching system associated
>>with them. For example UI events use capture/bubble dispatching
>>system and event queue. Events operate independently from their
>>handlers.
>>
>> Let's take a look on this example from IndexedDB spec:
>>
>> var request = indexedDB.open('AddressBook', 15);
>>  request.onsuccess = function(evt) {...};
>>  request.onerror = function(evt) {...};
>>
>> It looks *very* wrong to me:
>>
>> What should happen if db.open() will open the DB immediately?
>
> The event fires asynchronously. Since JS is single threaded that means
> that the onsuccess and onerror properties will be set before the event
> is fired.

1. Who said that JS *must* always be single threaded?

2. Is there any requirement that IndexedDB must be used only with JS?

3. Are you sure that opening DB or doing look-up on b-tree is always
   more expensive than posting and dispatching events? Windows
   for example uses 18ms precise timers ( used for dispatching
   non-UI events, or similar mechanism ).
   Are you saying that all operations in IndexedDB simply cannot work
   faster than that? If "yes" then who needs such brake by design?

If to compare look-up in b-tree on memory pages that are already in
cached and the task of posting/dispatching messages including
handler function invocation in script then ratio will be around 1:50.
What's the name of the design that puts such overhead upfront?

>
>> Will request.onsuccess be called in this case?
>
> Yes.
>
>> If indexedDB.open is purely async operation then
>> why it has to be exactly async?
>
> Because it requires IO.
>

1. Why exactly it requires IO? Why it cannot be implemented by using
main memory or memory-mapped files at the end ( not exactly IO
in classic sense )?
2. localStorage also uses IO, what's the problem you see with it at the
moment?
3. Which operation in IndexedDB require significantly more
time to execute than corresponding one from localStorage?
4. What's wrong with Web Workers that were designed specifically for
cases when operations takes long time? I do not see what
operation can take long time in IndexedDB but still would like
to know answer.

>> What may take time there other
>> than opening local file in worst case? If that request is async then
>> when precisely request.onsuccess will be called?
>>
>> I would understand if DB.open call will be defined this way:
>>
>> function onsuccess(evt) {...};
>> function onerror(evt) {...};
>>
>> var request = indexedDB.open('AddressBook', 15, onsuccess, onerror );
>>
>> (so pure callback operation).
>
> If I write
>
> var x = 0;
> function onsuccess(evt) { x = 1 };
> function onerror(evt) {...};
> var request = indexedDB.open('AddressBook', 15, onsuccess, onerror );
> console.log(x);
>
> would you expect the console to sometimes show 1 and sometimes show 0?
> If not, why not?

I am not sure I understand you here.

This form:
   indexedDB.open('AddressBook', 15, onsuccess, onerror );

does not limit UA engineers to chose the most optimal implementation.
So such open() may or may not use async model. But current spec
mandates the most ineffective variant. By design.

But in general there is no need for callback/events for operations on
such small DBs. SQLi