W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2014

Re: [whatwg] resource hints and separating download from processing

From: Ben Maurer <ben.maurer@gmail.com>
Date: Thu, 7 Aug 2014 23:17:07 -0700
Message-ID: <CABgOVaLS6ChjHgXnz_u_Ys4zBqiPMuN3z27=gk0gpREgLRFp9w@mail.gmail.com>
To: Ilya Grigorik <igrigorik@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>
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 <igrigorik@gmail.com> wrote:

> 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 06:17:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC