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

On Thu, Aug 7, 2014 at 2:55 PM, Ben Maurer <ben.maurer@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 <igrigorik@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
>>
>
>

Received on Thursday, 7 August 2014 22:22:20 UTC