Re: Fetch groups

On Tue, 25 Jun 2013, Anne van Kesteren wrote:
> 
> 1) We cannot directly share the Document object with individual fetches 
> as long term we might want fetching to be happen off-the-main-thread. 
> For workers this is already the case.

As long as it's not exposed to script, we probably can. Workers, for 
instance, keep track of Documents internally.


> 2) A fetch group would allow for shared state among a bunch of fetches, 
> such as origin, referrer, and CSP policy.

That state is currently managed via a Document, no?


> 3) If we merge CSP and Fetch by having a CSP parameter to fetch, we can 
> handle the load images directly from disk if the URL has been fetched 
> for the Document before via this fetch group. HTML, CSS, SVG, et al 
> would fetch images using the 'image-src' CSP parameter and the rest 
> would follow automatically.

Note that the "list of available images" is allowed to be copied from doc 
to doc, it's not really scoped to the "fetch group".


> 4) Lifetime of a Document becomes somewhat more explicit than "fetches 
> associated with this Document" although this seems one of the lesser 
> benefits.

Not sure I follow this.


> Now if we don't want to have fetch groups we need something for the 
> following instead:
> 
> 1) A way to load images without hitting the network for known URLs that 
> can be used across HTML, CSS, SVG, et al.
> 
> 2) An easy way to identify both the CSP policy in effect for a 
> particular fetch operation (the Content-Security-Policy header and its 
> reporting friend) as well as the CSP type (e.g. 'image-src').

I'd just use the Document as the key.

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

Received on Tuesday, 25 June 2013 18:36:08 UTC