Previously registered requestFilters are not used in the NetworkingEngine for a PreloadManager.

[jason-s13r]

Have you read the FAQ and checked for duplicate open issues?
Yes, though this #6616 closed issue is similar and I left a comment there.

If the problem is related to FairPlay, have you read the tutorial?
No.

What version of Shaka Player are you using?
4.8.7.

Can you reproduce the issue with our latest release version?
Yes.

Can you reproduce the issue with the latest code from main?
Yes.

Are you using the demo app or your own custom app?
Custom.

If custom app, can you reproduce the issue using our demo app?
Yes.

What browser and OS are you using?
Chrome, Safari; Windows, MacOS.

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?
From demo.

What configuration are you using? What is the output of player.getConfiguration()?
With default from demo.

What did you do?

We've been having trouble with shaka.media.PreloadManager not sending cookies with preload requests despite the player's networking engine having a request filter to set request.allowCrossSiteCredentials = true.

I believe that this is due to the shaka.Player.makePreloadManager_ creating a networking engine for the preload manager in /lib/player.js#L2109.
const networkingEngine = this.createNetworkingEngine(getPreloadManager);

This new networking engine has empty sets for requestFilters_ and responseFilters_ for the preload manager.

I think a PreloadManager should expose a getNetworkingEngine(), and/or copy the sets from the player's networking engine, or use the same networking engine.

Using the Shaka demo website with uncompiled v4.8.7, I can use in the JS console:

const player = new shaka.Player();
await player.attach(document.getElementById('video'));

player.getNetworkingEngine().registerRequestFilter(function (_type, request) {
  request.uris = request.uris.map(uri => uri + (uri.includes('?') ? '&' : '?') + '__viaRequestFilter=true');
});

const manager = await player.preload(shakaAssets.testAssets[1].manifestUri);
manager.networkingEngine_.registerRequestFilter(function (_type, request) {
  request.uris = request.uris.map(uri => uri + (uri.includes('?') ? '&' : '?') + '__preload=true');
});


const manager2 = await player.preload(shakaAssets.testAssets[1].manifestUri);

What did you expect to happen?
I expected requests made from a PreloadManager to have the adjustments made by the registered request filter from the player's networking engine (ie, contains ?__viaRequestFilter=true).
In our custom app, this would be to set request.allowCrossSiteCredentials = true.

What actually happened?
Manifest requests are preloaded as-expected, using the request filters previously registered with player.getNetworkingEngine().registerRequestFilter().
But the preloaded segment requests, and perhaps other requests types, do not appear to use the same filters.
In our custom app, the failure to set request.allowCrossSiteCredentials = true causes 403 on the preloaded requests.

Are you planning send a PR to fix it?
Perhaps, at least to add getNetworkingEngine() to shaka.media.PreloadManager.

[jason-s13r]

Here's a suggested fix.

It adds a getNetworkingEngine() to PreloadManager.
It copies the filters from the Player.networkingEngine_ to the PreloadManager.networkingEngine_ upon creating the PreloadManager.

jason-s13r@044bae7

[theodab]

That solution could work, but I don't want to offload too much of the work in getting the preload system to work onto the developer. It should ideally be as painless as possible to adopt.

For various technical reasons (stuff like tracking stats) we make a new networking engine for each preload manager.
Changing that might be possible, but I fear it'd be complicated. Instead, it might be easier to just have the new networking engine copy over any filter present in the player's networking engine, at the time the preload manager was made. Unless someone makes a habit of changing networking filters mid-playback, that should be a fairly simple-to-implement change that solves this issue. I'll give it a try.

[jason-s13r]

Yep, agree on making it easy for the application developer.

The commit I made used that approach to copy each of the requestFilters_ from the Player's networking engine to the PreloadManager's networking engine. As well as the responseFilters_.

I'll be happy to open a PR with that commit.

[avelad]

@jason-s13r see: #6709

[theodab]

Whoops, I totally did not notice the commit you linked.
Oh well. I guess I'll take it as a vote of confidence that the PR we just merged is a solution that will work for you.