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.


Reply via email to