`<link rel=preload>` should definitely follow the CSP rules that `as` implies. 

Malte - do you have a test case handy showing preload bypassing CSP? Is that something you see across various `as` values?

I just redid my experiments

No "as" value ignores default-src 'none'
If as value is provided, the CSP is respected and the request is silently dropped.

So, I think the only bug (and confusion) here is, that the violations do not trigger any error:
- no error in console
- no CSP report sent

When "as" is missing, CSP behavior should be identical to XHR. Is that not the case? Do you have a test case that shows the issue?

yoav@ Just confirming: Did you see my last comment regarding console and CSP reports?

Here is a repro case: http://output.jsbin.com/sopafuqiha/quiet
No message is being printed to the console for the blocked request.

I can recreate it. CSP directives are also not properly applied on `media` destinations.

Note, that if the currently observed behavior, that preload without `as` doesn't trigger CSP, but does get picked up by eventual downloads, breaks, <link rel=preload> becomes useless for us.

The ability to preload items that are only allowed by child frame CSP, but not the current frame is absolutely crucial for performance on the web.

Malte: do you control and/or know the CSP policy of the child frame? If you do, you should update the parent policy to be a superset of the child's policy, which would give you the behavior that you want.

Re, `as` without a value: these fetches are subject to connect-src, same as fetch(). If that policy is not enforced today, then that's a bug. 

Also, if you're attempting to use resources across frames.. I think you should be looking at prefetch, not preload. Preload responses are tied to the fetch group of the frame that initiated them, whereas prefetch responses are more flexible and can be reused across contexts.

What we've been seeing with prefetch is that child frames do not pick it up (they make an entirely new request), if the request has not been completed by the time the child frame makes it. This seems to work great with preload. I suppose our empirical results point to the opposite of what you are describing.

Here is the scenario:
- We make an iframe to draw an ad.
- We know the ad iframe will eventually request JS file X, and so we want to preload it.
- Under absolutely no circumstance do we want to allow execution of X in our main document (so we cannot add it to the CSP).

Malte, sounds like what you're looking for (as Ilya suggests) is a (potentially high-priority) `prefetch`.

Preload is not the right primitive both from a CSP perspective, and from the fact that the iframe will likely not share the same MemCache as the parent document. So, if the resource you're preloading is non-cacheable, you're likely to double-download it.

Malte: If you believe prefetch is not behaving as it should, can you please open a separate bug for that, with a simple test case that shows the issues you're encountering? (and CCing me on it?)

Hmm, maybe I should retest, but our results where conclusive:

- prefetch would double download (not intercept in process requests)
- preload would work as we expected.

Was there any change to the behavior in the last 2 month or so?

Not an intentional one

> What we've been seeing with prefetch is that child frames do not pick it up (they make an entirely new request), if the request has not been completed by the time the child frame makes it. This seems to work great with preload. I suppose our empirical results point to the opposite of what you are describing.

I'm more than willing to believe that this is true of current Chrome implementation. My comment, however, is from where we want to head, not where we are. We're starting to untangle the mess of various (unspecified) caches, and roughly we're looking at: 

- Preload responses* will be attached to the Fetch group. When the fetch group goes away (e.g. page is unloaded), they're dropped on the floor. Similarly, different renderer's will have own context and Fetch group. So, preloading a resource in context A does not grant access to it in context B.
- Prefetch responses *are* meant to be reusable across contexts and are not tied to the Fetch group. This is, I believe, what you're after, because you want to prefetch a response that will be used in a different frame. Hence, my comment above.

Finally, the prefetch behavior of duplicating the download sounds.. like a bug that we should investigate.


* note that above applies for non-cacheable responses. IF the response is cacheable by the HTTP cache, then it's reusable regardless of preload/prefetch distinction.

Actually, verifying the test again, CSP seems to be working as intended, including 'default-src' directives on preloads with no 'as' attribute. 

I am seeing the fact that violation reports and console warnings are not emitted. Changing the issue's title accordingly.

I think we have definitely been confused by how all these things relate to caching. I retested and picking up responses from prefetch does work if the response is cacheable and my measurements now show that they don't get picked up for preload when they are not cacheable.

The new title makes sense. I thought there was a separate bug for that. Fixing it will make this 100x less confusing!