Re: [whatwg] resource hints and separating download from processing
On Mon, 11 Aug 2014, Ilya Grigorik wrote: On Mon, Aug 11, 2014 at 12:57 PM, Ian Hickson i...@hixie.ch wrote: I hope to be able to post more concrete proposals soon, it's currently blocked on my understanding how I should be integrating HTML with ES6. Any bugs or threads that I can follow to track progress? I'd love to help if I can. My understanding of ES6 is mostly being helped by discussions on #whatwg and e-mail threads to es-discuss. Two high-level cases: (a) optimizing load sequence of page that's currently being loaded (b) optimizing page load of a (potential) future navigation For (a), we need to expose preconnect and preload, such that the developer and/or server (e.g. CDN accelerator) can tell the browser which hosts it should connect to, which resources it should load (+ with which priority, order), etc. Also, note that preload separates download from processing, which is an important feature - e.g. fetch CSS but don't evaluate it. Preload is straight forward, sure. How much does preconnect within a page actually help? Isn't just declaring the URLs enough? I don't really see how you expect this to be used or exposed. For (b), we're talking about a speculative hint, hence we attach a probability to the hint and let the UA decide if it has enough resources / time / etc, to execute it, and how far it is willing to go with response processing. The ability to tell a page what subsequent resources will be necessary (prerendering) seems pretty straight-forward too, sure. That's mostly a solved problem with rel=prerender, no? Anything we add to make fetching more powerful will automatically be exposed to that too, presumably. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Fri, Aug 15, 2014 at 9:26 AM, Ian Hickson i...@hixie.ch wrote: Two high-level cases: (a) optimizing load sequence of page that's currently being loaded (b) optimizing page load of a (potential) future navigation For (a), we need to expose preconnect and preload, such that the developer and/or server (e.g. CDN accelerator) can tell the browser which hosts it should connect to, which resources it should load (+ with which priority, order), etc. Also, note that preload separates download from processing, which is an important feature - e.g. fetch CSS but don't evaluate it. Preload is straight forward, sure. How much does preconnect within a page actually help? Isn't just declaring the URLs enough? I don't really see how you expect this to be used or exposed. It's often the case that you don't know the exact URL you want to fetch (e.g. the URL is generated based on local client context, etc), but you know that you *will* connect to a certain host - lots of third party widgets, fonts, etc, fall into this category. As a concrete example: - link href='https://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' - above stylesheet is dynamic and returns a pointer to a UA optimized font file that lives on https://fonts.gstatic.com As a result, I know that I'll need a connection to https://fonts.gstatic.com, but I don't know the exact URL. Also, because we're talking HTTPS, we're looking at up to 4 RTTs (DNS, TCP, TLS), which can easily translate to 1s+ on mobile connections. Issuing an early preconnect allows us to hide some or all of this latency. Another example is improving performance of redirect click trackers, see example 2: https://igrigorik.github.io/resource-hints/#preconnect For (b), we're talking about a speculative hint, hence we attach a probability to the hint and let the UA decide if it has enough resources / time / etc, to execute it, and how far it is willing to go with response processing. The ability to tell a page what subsequent resources will be necessary (prerendering) seems pretty straight-forward too, sure. That's mostly a solved problem with rel=prerender, no? Anything we add to make fetching more powerful will automatically be exposed to that too, presumably. Solved in the sense that we have the attributed listed in the HTML spec. Not solved in the sense that current implementations of prerender can (and need to) be significantly improved - e.g. how they handle different content types, how they handle resource contention, how the developer can communicate the context/probability of using the hinted resource, the APIs available to invoke these actions (dynamic scheduling/canceling, HTTP headers), and so on. Further, now that we have multiple implementations (Chrome, IE, and FF has started working on it), we need a common spec such that we can deliver a consistent API and experience. That said, I think we're on the same page... I'm just arguing that X will subsume resource hints is not entirely true: we still need to define how preconnect/preload/prerender need to behave, which APIs they will expose, what guarantees they will provide, and so on. None of that is currently spec'ed, which is the gap I'm trying to fill. ig
Re: [whatwg] resource hints and separating download from processing
On Fri, 15 Aug 2014, Ilya Grigorik wrote: - link href='https://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' - above stylesheet is dynamic and returns a pointer to a UA optimized font file that lives on https://fonts.gstatic.com Ah, yeah, that's an excellent example. Thanks. That said, I think we're on the same page... I'm just arguing that X will subsume resource hints is not entirely true: we still need to define how preconnect/preload/prerender need to behave, which APIs they will expose, what guarantees they will provide, and so on. None of that is currently spec'ed, which is the gap I'm trying to fill. I totally agree that more detailed specs for rel=prerender, rel=preconnect, and rel=prefetch/preload/subresource would be useful. I may end up speccing the latter, but what I'm doing doesn't so far have any direct impact on the former two. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Thu, 7 Aug 2014, Ilya Grigorik wrote: I'm working on the resource hints spec we've been discussing on public-webperf... FYI, I'm currently working an a dependency system update to HTML which has the goals of: - merging HTML import dependency management and ES6 module dependency management infrastructure - defining preloading mechanisms for most HTML loading contexts - defining a dependency system for HTML loading contexts, especially style sheets, images, HTML imports, modules, and scripts - hooking most HTML loading contexts into the new Fetch API Assuming this works out as intended, it would completely subsume the resource hints proposal. My main blocker right now is the part where it gets integrated into the ES6 module system; it's requiring some very careful reading of the ES6 spec. I'm still in the middle of this. You can see my current results here: http://www.gliffy.com/go/publish/6040024 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Mon, Aug 11, 2014 at 8:33 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 7 Aug 2014, Ilya Grigorik wrote: I'm working on the resource hints spec we've been discussing on public-webperf... FYI, I'm currently working an a dependency system update to HTML which has the goals of: - merging HTML import dependency management and ES6 module dependency management infrastructure Will this result in API that extends beyond import and ES6 module use cases? For example, I want to have the building blocks that will allow me to declare these dependencies on my own: these two images before that script, but after this stylesheet, oh and that stylesheet should have higher priority than... We can express all of this in HTTP/2, and I'd like that to be surfaced to the developers as a first class API. - defining preloading mechanisms for most HTML loading contexts - defining a dependency system for HTML loading contexts, especially style sheets, images, HTML imports, modules, and scripts I'm looking at the gliffy, but having a hard time understanding how this will work... It's murky to me how I'd declare a resource, specify its priority relative to others, and/or add a dependency. Any other (more complete) examples, by any chance? :) - hooking most HTML loading contexts into the new Fetch API Great! Assuming this works out as intended, it would completely subsume the resource hints proposal. Hmm, not entirely.. I think. At a minimum, we still have preconnect and speculative preload + prerender cases to consider. ig
Re: [whatwg] resource hints and separating download from processing
On Mon, 11 Aug 2014, Ilya Grigorik wrote: Will this result in API that extends beyond import and ES6 module use cases? For example, I want to have the building blocks that will allow me to declare these dependencies on my own: these two images before that script, but after this stylesheet, oh and that stylesheet should have higher priority than... We can express all of this in HTTP/2, and I'd like that to be surfaced to the developers as a first class API. Yeah, this is the kind of thing I'm looking at. - defining preloading mechanisms for most HTML loading contexts - defining a dependency system for HTML loading contexts, especially style sheets, images, HTML imports, modules, and scripts I'm looking at the gliffy The gliffy is just a description of the ES6 module system. but having a hard time understanding how this will work... You and me both. It's murky to me how I'd declare a resource, specify its priority relative to others, and/or add a dependency. Any other (more complete) examples, by any chance? :) All of that is out of scope of ES6 (and thus the gliffy), but is what I'm trying to design. I hope to be able to post more concrete proposals soon, it's currently blocked on my understanding how I should be integrating HTML with ES6. Assuming this works out as intended, it would completely subsume the resource hints proposal. Hmm, not entirely.. I think. At a minimum, we still have preconnect and speculative preload + prerender cases to consider. Do you mean the case of fetching a file before you've loaded the base HTML file, as in loading a landing page before the user has selected a search result on a search engine, for example? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Mon, Aug 11, 2014 at 12:57 PM, Ian Hickson i...@hixie.ch wrote: It's murky to me how I'd declare a resource, specify its priority relative to others, and/or add a dependency. Any other (more complete) examples, by any chance? :) All of that is out of scope of ES6 (and thus the gliffy), but is what I'm trying to design. I hope to be able to post more concrete proposals soon, it's currently blocked on my understanding how I should be integrating HTML with ES6. Any bugs or threads that I can follow to track progress? I'd love to help if I can. Assuming this works out as intended, it would completely subsume the resource hints proposal. Hmm, not entirely.. I think. At a minimum, we still have preconnect and speculative preload + prerender cases to consider. Do you mean the case of fetching a file before you've loaded the base HTML file, as in loading a landing page before the user has selected a search result on a search engine, for example? Two high-level cases: (a) optimizing load sequence of page that's currently being loaded (b) optimizing page load of a (potential) future navigation For (a), we need to expose preconnect and preload, such that the developer and/or server (e.g. CDN accelerator) can tell the browser which hosts it should connect to, which resources it should load (+ with which priority, order), etc. Also, note that preload separates download from processing, which is an important feature - e.g. fetch CSS but don't evaluate it. For (b), we're talking about a speculative hint, hence we attach a probability to the hint and let the UA decide if it has enough resources / time / etc, to execute it, and how far it is willing to go with response processing. For more detailed use cases, check out Example 1-9: https://igrigorik.github.io/resource-hints/ ig
Re: [whatwg] resource hints and separating download from processing
Sweet, I think we're on the same page. I completely agree with your high
level goal of a declarative fetch interface.
Agreed that matching is still critical, eg for the Link header use case.
On Thu, Aug 7, 2014 at 10:40 PM, Ilya Grigorik igrigo...@gmail.com wrote:
On Thu, Aug 7, 2014 at 4:39 PM, Ben Maurer ben.mau...@gmail.com wrote:
On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik igrigo...@gmail.com
wrote:
It would be nice if there was a more declarative relationship between
the declarative fetch and the eventual use of the resource (assuming the
resources are on the same page).
I would like to break that dependency. I want layering separation where
we have a clean way to fetch resources (with custom parameters like
headers, priorities, dependencies, etc), and a layer that's responsible for
consuming fetched resources for processing in the right context (enforcing
security policies, etc), and at the right time -- e.g. see Example 3 under:
https://igrigorik.github.io/resource-hints/#preload
So I guess my worry here is that the loose dependency could be hard to
debug. As a concrete example, we use crossorigin=anonymous on our script
tags so that we can get stack traces. My understanding is that this
requires an Origin header to be sent with the request and a CORS header in
the response. If my link rel=preload doesn't have a crossorigin
setting, the requests wouldn't match up.
We can't control the response bits, but as far as emitting the right
request headers and communicating stream priority + dependencies, all of
that could be exposed via some set of options when the request is built up.
This is where we get back to the syntax (e.g. params={...}, or some
such), which would probably map directly to various Fetch API use cases and
options. Effectively, I want a declarative Fetch interface.
I guess what I'm asking for here is some programmatic way of connecting
the fetch with the consumption. For example, exposing the fetch object of
the rel=preload and allowing you to construct a script tag explicitly with
the fetch object.
+1. That said, we still *need* a mechanism where the matching does not
rely on manual plumbing with JavaScript - e.g. server returns a set of
hints via Link header for critical resources, which must be matched by the
user agent against appropriate requests later in the doc.
ig
Re: [whatwg] resource hints and separating download from processing
+1 to breaking the dependency between fetching the resource and how it is later
used in the document. This type of “late binding” enables many page
optimizations.
Peter
PS. My apologies if you’ve already seen a message saying similar. I’m not sure
if the mailing list is accepting my messages or not yet.
On Aug 8, 2014, at 2:17 AM, Ben Maurer ben.mau...@gmail.com wrote:
Sweet, I think we're on the same page. I completely agree with your high
level goal of a declarative fetch interface.
Agreed that matching is still critical, eg for the Link header use case.
On Thu, Aug 7, 2014 at 10:40 PM, Ilya Grigorik igrigo...@gmail.com wrote:
On Thu, Aug 7, 2014 at 4:39 PM, Ben Maurer ben.mau...@gmail.com wrote:
On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik igrigo...@gmail.com
wrote:
It would be nice if there was a more declarative relationship between
the declarative fetch and the eventual use of the resource (assuming the
resources are on the same page).
I would like to break that dependency. I want layering separation where
we have a clean way to fetch resources (with custom parameters like
headers, priorities, dependencies, etc), and a layer that's responsible for
consuming fetched resources for processing in the right context (enforcing
security policies, etc), and at the right time -- e.g. see Example 3 under:
https://igrigorik.github.io/resource-hints/#preload
So I guess my worry here is that the loose dependency could be hard to
debug. As a concrete example, we use crossorigin=anonymous on our script
tags so that we can get stack traces. My understanding is that this
requires an Origin header to be sent with the request and a CORS header in
the response. If my link rel=preload doesn't have a crossorigin
setting, the requests wouldn't match up.
We can't control the response bits, but as far as emitting the right
request headers and communicating stream priority + dependencies, all of
that could be exposed via some set of options when the request is built up.
This is where we get back to the syntax (e.g. params={...}, or some
such), which would probably map directly to various Fetch API use cases and
options. Effectively, I want a declarative Fetch interface.
I guess what I'm asking for here is some programmatic way of connecting
the fetch with the consumption. For example, exposing the fetch object of
the rel=preload and allowing you to construct a script tag explicitly with
the fetch object.
+1. That said, we still *need* a mechanism where the matching does not
rely on manual plumbing with JavaScript - e.g. server returns a set of
hints via Link header for critical resources, which must be matched by the
user agent against appropriate requests later in the doc.
ig
[whatwg] resource hints and separating download from processing
I'm working on the resource hints spec we've been discussing on
public-webperf...
This specification defines preconnect, preload, and prerender hints that
the developer, or the server generating or delivering the resources, can
use in an interoperable way to assist the user agent in the decision
process of which origins it should connect to, which resources it should
fetch to improve performance, and which resources may be required by the
next navigation.
Latest draft: https://igrigorik.github.io/resource-hints/
There are still plenty of details to iron out [1] and I'd appreciate any
thoughts or feedback, but in particular I'm interested on suggestions
around this discussion: https://github.com/igrigorik/resource-hints/issues/6
Some background... Current browsers use resource context and content-type
as a signal for download priority (e.g. scripts get a higher download
priority than images). This is an imperfect signal, but it has served us
well. As a result, in first iteration of the spec I went with type
attribute (on link) as a way to communicate same information to the user
agent. Later (see issue above), it was suggested that context is a better
mechanism to express this and I agree.. except, it opens up a different set
of questions and challenges:
- There are cases where context is known: image, script, etc.
- There are cases where context depends on multiple signals: iframe vs.
iframe+seamless
- There are cases where context is not known precisely ahead of time - e.g.
prerender navigation can be triggered via multiple mechanisms (link click,
window.location, etc).
Long story short, the problem is that context is coupling download,
policy enforcement, and processing. I'm wondering if we should separate
these into:
(1) a mechanism for downloading resources with right priority, etc.
(2) a mechanism for processing downloaded resources where security and
other policies are applied.
Today, CSP blocks requests *before* they are issued. What I'm after here is
applying CSP (and other relevant policies) on a resource that was already
downloaded or is currently in flight -- I believe this is a requirement for
ServiceWorker anyway? I'm sure there are other examples where this is
relevant also.
Separating downloading from processing would expose an important and very
useful platform primitive: it'll allow us (regular developers) to compose
different download behaviors, define when resources are processed and in
which order, etc.
More concretely, picture something like this (don't pay too much attention
to syntax, just hand waving):
(1) link rel=preload href=//thirdparty.com/script.js
execution=required params={...}
...
(2) script src=//thirdparty.com/script.js
(3) script xhr = new XMLHttpRequest(); xhr.get(//thirdparty.com/script.js
);
---
#1: initiates immediate download - effectively, it's a declarative fetch.
You can also specify execution [2] and other request parameters [via 3, or
something like it].
#2: script request is matched [4] against the preload request, proper
policies are applied and if that checks out, it's processed and executed.
#3: XHR request is matched against preload, proper policies are applied..
and it may get blocked due to same-origin restrictions, or some such.
Assuming this makes sense, I'd drop context and instead rely on
communicating download priority via [3], or something similar. As an aside,
I think [3] is not going far enough, but that's a subject for a separate
thread.
Thoughts?
ig
[1] https://github.com/igrigorik/resource-hints/issues
[2]
https://igrigorik.github.io/resource-hints/#required-vs-speculative-execution
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533
[4]
https://github.com/igrigorik/resource-hints/issues/5#issuecomment-50809768
Re: [whatwg] resource hints and separating download from processing
Hey,
Not sure if you've seen this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html.
I had the same basic interest as you (decoupling resource fetching from
execution). I'd be curious to hear your thoughts about that thread.
I really like the concept of a declarative fetch -- being able to specify
arbitrary fetch parameters (eg, headers or a yet-to-be-defined interface to
define HTTP/2 priority) is very powerful. It would be nice if there was a
more declarative relationship between the declarative fetch and the
eventual use of the resource (assuming the resources are on the same page).
For example, in the thread I had suggested fetch.asScript() though it seems
like people preferred using an actual script tag to initiate the fetch
(with a parameter saying not to execute).
-b
On Thu, Aug 7, 2014 at 2:04 PM, Ilya Grigorik igrigo...@gmail.com wrote:
I'm working on the resource hints spec we've been discussing on
public-webperf...
This specification defines preconnect, preload, and prerender hints that
the developer, or the server generating or delivering the resources, can
use in an interoperable way to assist the user agent in the decision
process of which origins it should connect to, which resources it should
fetch to improve performance, and which resources may be required by the
next navigation.
Latest draft: https://igrigorik.github.io/resource-hints/
There are still plenty of details to iron out [1] and I'd appreciate any
thoughts or feedback, but in particular I'm interested on suggestions
around this discussion:
https://github.com/igrigorik/resource-hints/issues/6
Some background... Current browsers use resource context and content-type
as a signal for download priority (e.g. scripts get a higher download
priority than images). This is an imperfect signal, but it has served us
well. As a result, in first iteration of the spec I went with type
attribute (on link) as a way to communicate same information to the user
agent. Later (see issue above), it was suggested that context is a better
mechanism to express this and I agree.. except, it opens up a different set
of questions and challenges:
- There are cases where context is known: image, script, etc.
- There are cases where context depends on multiple signals: iframe vs.
iframe+seamless
- There are cases where context is not known precisely ahead of time - e.g.
prerender navigation can be triggered via multiple mechanisms (link click,
window.location, etc).
Long story short, the problem is that context is coupling download,
policy enforcement, and processing. I'm wondering if we should separate
these into:
(1) a mechanism for downloading resources with right priority, etc.
(2) a mechanism for processing downloaded resources where security and
other policies are applied.
Today, CSP blocks requests *before* they are issued. What I'm after here is
applying CSP (and other relevant policies) on a resource that was already
downloaded or is currently in flight -- I believe this is a requirement for
ServiceWorker anyway? I'm sure there are other examples where this is
relevant also.
Separating downloading from processing would expose an important and very
useful platform primitive: it'll allow us (regular developers) to compose
different download behaviors, define when resources are processed and in
which order, etc.
More concretely, picture something like this (don't pay too much attention
to syntax, just hand waving):
(1) link rel=preload href=//thirdparty.com/script.js
execution=required params={...}
...
(2) script src=//thirdparty.com/script.js
(3) script xhr = new XMLHttpRequest(); xhr.get(//
thirdparty.com/script.js
);
---
#1: initiates immediate download - effectively, it's a declarative fetch.
You can also specify execution [2] and other request parameters [via 3, or
something like it].
#2: script request is matched [4] against the preload request, proper
policies are applied and if that checks out, it's processed and executed.
#3: XHR request is matched against preload, proper policies are applied..
and it may get blocked due to same-origin restrictions, or some such.
Assuming this makes sense, I'd drop context and instead rely on
communicating download priority via [3], or something similar. As an aside,
I think [3] is not going far enough, but that's a subject for a separate
thread.
Thoughts?
ig
[1] https://github.com/igrigorik/resource-hints/issues
[2]
https://igrigorik.github.io/resource-hints/#required-vs-speculative-execution
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533
[4]
https://github.com/igrigorik/resource-hints/issues/5#issuecomment-50809768
Re: [whatwg] resource hints and separating download from processing
On Thu, Aug 7, 2014 at 2:55 PM, Ben Maurer ben.mau...@gmail.com wrote:
Not sure if you've seen this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html.
I had the same basic interest as you (decoupling resource fetching from
execution). I'd be curious to hear your thoughts about that thread.
My bad, my [3] reference was supposed to point to your exact link above.
In terms of feedback on that thread: I really like where its heading and
some of the proposals in there, but I think we need to think a bit more
about the right mechanism to expose download priorities and dependencies
now that we have these capabilities at the transport layer in HTTP/2.
It would be nice if there was a more declarative relationship between the
declarative fetch and the eventual use of the resource (assuming the
resources are on the same page).
I would like to break that dependency. I want layering separation where we
have a clean way to fetch resources (with custom parameters like headers,
priorities, dependencies, etc), and a layer that's responsible for
consuming fetched resources for processing in the right context (enforcing
security policies, etc), and at the right time -- e.g. see Example 3 under:
https://igrigorik.github.io/resource-hints/#preload
That's not to say that we can't set sane defaults (headers, etc) based on
context (when its known) when initiating the download (e.g. script, image,
etc), but I don't think we should couple the two.
For example, in the thread I had suggested fetch.asScript() though it seems
like people preferred using an actual script tag to initiate the fetch
(with a parameter saying not to execute).
Not all scripts are made equal. There are cases where an image may be more
important that script, etc. Also, defining a do not execute bit on every
element seems painful. I'd rather have a fetch layer, and then just inject
the tag that would consume the fetched response and execute it when
injected -- seems cleaner.
ig
On Thu, Aug 7, 2014 at 2:04 PM, Ilya Grigorik igrigo...@gmail.com wrote:
I'm working on the resource hints spec we've been discussing on
public-webperf...
This specification defines preconnect, preload, and prerender hints that
the developer, or the server generating or delivering the resources, can
use in an interoperable way to assist the user agent in the decision
process of which origins it should connect to, which resources it should
fetch to improve performance, and which resources may be required by the
next navigation.
Latest draft: https://igrigorik.github.io/resource-hints/
There are still plenty of details to iron out [1] and I'd appreciate any
thoughts or feedback, but in particular I'm interested on suggestions
around this discussion:
https://github.com/igrigorik/resource-hints/issues/6
Some background... Current browsers use resource context and content-type
as a signal for download priority (e.g. scripts get a higher download
priority than images). This is an imperfect signal, but it has served us
well. As a result, in first iteration of the spec I went with type
attribute (on link) as a way to communicate same information to the user
agent. Later (see issue above), it was suggested that context is a
better
mechanism to express this and I agree.. except, it opens up a different
set
of questions and challenges:
- There are cases where context is known: image, script, etc.
- There are cases where context depends on multiple signals: iframe vs.
iframe+seamless
- There are cases where context is not known precisely ahead of time -
e.g.
prerender navigation can be triggered via multiple mechanisms (link click,
window.location, etc).
Long story short, the problem is that context is coupling download,
policy enforcement, and processing. I'm wondering if we should separate
these into:
(1) a mechanism for downloading resources with right priority, etc.
(2) a mechanism for processing downloaded resources where security and
other policies are applied.
Today, CSP blocks requests *before* they are issued. What I'm after here
is
applying CSP (and other relevant policies) on a resource that was already
downloaded or is currently in flight -- I believe this is a requirement
for
ServiceWorker anyway? I'm sure there are other examples where this is
relevant also.
Separating downloading from processing would expose an important and very
useful platform primitive: it'll allow us (regular developers) to compose
different download behaviors, define when resources are processed and in
which order, etc.
More concretely, picture something like this (don't pay too much attention
to syntax, just hand waving):
(1) link rel=preload href=//thirdparty.com/script.js
execution=required params={...}
...
(2) script src=//thirdparty.com/script.js
(3) script xhr = new XMLHttpRequest(); xhr.get(//
thirdparty.com/script.js
);
---
#1: initiates immediate download - effectively, it's a
Re: [whatwg] resource hints and separating download from processing
On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik igrigo...@gmail.com wrote: It would be nice if there was a more declarative relationship between the declarative fetch and the eventual use of the resource (assuming the resources are on the same page). I would like to break that dependency. I want layering separation where we have a clean way to fetch resources (with custom parameters like headers, priorities, dependencies, etc), and a layer that's responsible for consuming fetched resources for processing in the right context (enforcing security policies, etc), and at the right time -- e.g. see Example 3 under: https://igrigorik.github.io/resource-hints/#preload So I guess my worry here is that the loose dependency could be hard to debug. As a concrete example, we use crossorigin=anonymous on our script tags so that we can get stack traces. My understanding is that this requires an Origin header to be sent with the request and a CORS header in the response. If my link rel=preload doesn't have a crossorigin setting, the requests wouldn't match up. I guess what I'm asking for here is some programmatic way of connecting the fetch with the consumption. For example, exposing the fetch object of the rel=preload and allowing you to construct a script tag explicitly with the fetch object. -b
Re: [whatwg] resource hints and separating download from processing
On Thu, Aug 7, 2014 at 4:39 PM, Ben Maurer ben.mau...@gmail.com wrote:
On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik igrigo...@gmail.com wrote:
It would be nice if there was a more declarative relationship between the
declarative fetch and the eventual use of the resource (assuming the
resources are on the same page).
I would like to break that dependency. I want layering separation where
we have a clean way to fetch resources (with custom parameters like
headers, priorities, dependencies, etc), and a layer that's responsible for
consuming fetched resources for processing in the right context (enforcing
security policies, etc), and at the right time -- e.g. see Example 3 under:
https://igrigorik.github.io/resource-hints/#preload
So I guess my worry here is that the loose dependency could be hard to
debug. As a concrete example, we use crossorigin=anonymous on our script
tags so that we can get stack traces. My understanding is that this
requires an Origin header to be sent with the request and a CORS header in
the response. If my link rel=preload doesn't have a crossorigin
setting, the requests wouldn't match up.
We can't control the response bits, but as far as emitting the right
request headers and communicating stream priority + dependencies, all of
that could be exposed via some set of options when the request is built up.
This is where we get back to the syntax (e.g. params={...}, or some
such), which would probably map directly to various Fetch API use cases and
options. Effectively, I want a declarative Fetch interface.
I guess what I'm asking for here is some programmatic way of connecting
the fetch with the consumption. For example, exposing the fetch object of
the rel=preload and allowing you to construct a script tag explicitly with
the fetch object.
+1. That said, we still *need* a mechanism where the matching does not rely
on manual plumbing with JavaScript - e.g. server returns a set of hints via
Link header for critical resources, which must be matched by the user agent
against appropriate requests later in the doc.
ig
