- From: Ilya Grigorik <igrigorik@gmail.com>
- Date: Thu, 7 Aug 2014 22:40:49 -0700
- To: Ben Maurer <ben.maurer@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>
On Thu, Aug 7, 2014 at 4:39 PM, Ben Maurer <ben.maurer@gmail.com> wrote: > > On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik <igrigorik@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
Received on Friday, 8 August 2014 05:41:56 UTC