I forgot to mention that "Disable Cache" was checked as well. This makes me thinking this is related to https://bugs.chromium.org/p/chromium/issues/detail?id=652228 like https://bugs.chromium.org/p/chromium/issues/detail?id=734056.

This isn't quite media network related. The media stack just uses the URL information provided from Blink, we expect that either it provides us a different resource URI for such preloaded resources or that the underlying network stack is responsible for this preload behavior.

cc: those labels since I'm not sure which should actually be happening for rel=preload

Adding one of the preload spec authors, maybe they can clarify how this should work.

jww@ is no longer working on Chromium.

IIRC, <video> is using DocumentThreadableLoader. Currently, Chrome doesn't use data preloaded by a link element for DocumentThreadableLodaer-based stuff including XMLHttpRequest, fetch(), etc.

Until recently, Chrome accidentally allowed XHR to reuse data loaded by <link rel=preload> without crossOrigin attribute, but we also just disabled it.

Once we fix the loader architecture, we can make the combination of <link rel=preload crossOrigin> and DocumentThreadableLoader-based CORS-enabled APIs work again.

s/we also just disabled/we are about to disable/

Not sure what DocumentThreadableLoader is.
<video> calls CreateAssociatedURLLoader() on the frame and loads data through whatever it returns.

The video doesn't have "crossorigin" attribute, so the link preload shouldn't have it.

The script sets the href long after onload is fired. As the console warning

The resource https://storage.googleapis.com/fbeaufort-test/sample-video.webm was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing.

suggests, the preloaded resource is discarded at that time.

You're right. I've removed the "crossorigin" attribute from the demo.

Regarding the warning, I've updated the code to fetch a short piece of a video so that it the video src is used right after the onload event: https://github.com/beaufortfrancois/sandbox/commit/bbaea8759629fc29ea60976dfb743464640b58e2

See screenshot below. There is still something wrong but I'm not sure what...

Deleted: Screenshot 2017-10-06 at 10.42.42 AM.png 928 KB

	Screenshot 2017-10-06 at 10.42.42 AM.png 928 KB View Download

Ah, you're right.

The preloaded one is not used due to header difference: Accept-Encoding, Range and chrome-proxy in my environment. Among these, Range is crucial, I guess.

Probably Accept-Encoding also matters. I don't know about chrome-proxy.

Would you know how can I make sure these values are the same?

I see the difference (other than chrome-proxy) in devtools.

In Chrome 63.0.3230.0 (Official Build) canary (64-bit), I see only one request in DevTools.

In Stable though:
 - The "link preload" request has no range HTTP Headers while the "src" one has a range HTTP Header of "bytes=0-".
 - The "link preload" request has a "accept-encoding" HTTP Headers set to "gzip, deflate, br"  while the "src" one has a "accept-encoding" HTTP Header of "identity;q=1, *;q=0".

Blink::ResourceMultiBufferDataProvider attaches such headers but they're not consistent with preloads. Media people, can you take a look?

Take a look at what?
We need those headers.

Then you may need to add them to as=video preloads as well.

I suppose we could do that. But it would be somewhat error-prone so we'd need a test to make sure it doesn't randomly break. Where would I need to add this header?

 yhirano@ could you help me figure out how to fix as=video headers?

yhirano, ping?

Sorry for the delay.

> #22

core/link_loader.cc maybe.

So I made an attempt to add the headers ( https://chromium-review.googlesource.com/#/c/chromium/src/+/1067752 ) but it doesn't seem to work. The headers do not show up in the actual request. yhirano, could you take a look and tell me what I'm doing wrong?

What happens if you set Range?

Setting range should not affect caching.
If it did, then requesting a sub-range would not hit the cache.

link rel=preload is different from the HTTP cache. We don't have any Range related logic in that, so ignoring requests with different headers sounds good to me.

The video code will make many requests with different ranges against the same resource. For link preloading to work, it must ignore the range header I think.
Simply "set Range" doesn't work.

Then I think we should remove as="video" support from link rel="preload".

I support temporary removal. We need to properly define the preload cache and how it should work for media fetches and range requests: https://github.com/w3c/preload/issues/97

That will make it easier to then add such support to the preload cache.

Ok, so who should I assign this bug to?

Assigning to yharino to figure out who can remove the as=video support.