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 >