# Should apps force-register HttpFetchPlugin when isSupported() returns false?

**URL:** <https://community.amazondeveloper.com/t/should-apps-force-register-httpfetchplugin-when-issupported-returns-false/28715>\
**Category:** Q&A\
**Tags:** vega-media-player\
**Created:** [July 8, 2026, 9:05pm UTC](https://community.amazondeveloper.com/t/should-apps-force-register-httpfetchplugin-when-issupported-returns-false/28715 "2026-07-08T21:05:30Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![fubo-thughes](https://avatars.discourse-cdn.com/v4/letter/f/779978/32.png) [@fubo-thughes](https://community.amazondeveloper.com/u/fubo-thughes)\
**Post date:** [July 8, 2026, 9:05pm UTC](https://community.amazondeveloper.com/t/should-apps-force-register-httpfetchplugin-when-issupported-returns-false/28715/1 "2026-07-08T21:05:30Z")

</div>

# Should apps force-register `HttpFetchPlugin` on Vega/Fire TV when `isSupported()` returns `false`?

**Environment:** Vega SDK 0.23.8358 · `@amazon-devices/react-native-w3cmedia` 2.1.99 · Shaka Player 4.16.13 · Fire TV Stick

On our Fire TV Stick, `shaka.net.HttpFetchPlugin.isSupported()` returns `false`  
(it requires a constructible `ReadableStream` and `new Response('').body` —  
[shaka `http_fetch_plugin.js` L289-L315](https://github.com/shaka-project/shaka-player/blob/v4.16.13/lib/net/http_fetch_plugin.js#L289-L315)),  
so Shaka would normally fall back to `HttpXHRPlugin`.

But the Vega Video Sample App’s `ShakaPlayer.ts` explicitly unregisters the  
default http/https handlers and force-registers the fetch plugin at  
`APPLICATION` priority anyway:

- unregister: [`ShakaPlayer.ts` L283-L284](https://github.com/AmazonAppDev/vega-video-sample/blob/main/src/w3cmedia/shakaplayer/ShakaPlayer.ts#L283-L284)
- force-register fetch plugin: [`ShakaPlayer.ts` L290-L302](https://github.com/AmazonAppDev/vega-video-sample/blob/main/src/w3cmedia/shakaplayer/ShakaPlayer.ts#L290-L302)

```js
shaka.net.NetworkingEngine.unregisterScheme('http');
shaka.net.NetworkingEngine.unregisterScheme('https');

const httpFetchPluginSupported = shaka.net.HttpFetchPlugin.isSupported(); // false on Kepler

shaka.net.NetworkingEngine.registerScheme(
  'http',
  shaka.net.HttpFetchPlugin.parse,
  shaka.net.NetworkingEngine.PluginPriority.APPLICATION,
  true,
);
shaka.net.NetworkingEngine.registerScheme(
  'https',
  shaka.net.HttpFetchPlugin.parse,
  shaka.net.NetworkingEngine.PluginPriority.APPLICATION,
  true,
);

```

**Question:** Is force-registering `HttpFetchPlugin` intentional and the  
recommended networking path for Shaka on Vega, even though `isSupported()`  
reports `false`?

We ask because on the default XHR fallback path, Shaka’s ABR bandwidth estimate  
gets corrupted on our device (byte counts come back `NaN`, which pins ABR to the  
startup rendition). So we’re trying to understand whether force-registering the  
fetch plugin is the sanctioned workaround, or whether the XHR path is expected  
to work. (Happy to share the detailed XHR/`NaN` root-cause analysis if useful.)

---

<div class="post-metadata">

**Author:** ![amen](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@amen](https://community.amazondeveloper.com/u/amen)\
**Post date:** [July 8, 2026, 9:56pm UTC](https://community.amazondeveloper.com/t/should-apps-force-register-httpfetchplugin-when-issupported-returns-false/28715/4 "2026-07-08T21:56:42Z")

</div>

Hi @fubo-thughes,

Great question - thank you for providing the specific code references.

Yes, force-registering HttpFetchPlugin is intentional and the recommended networking path for Shaka Player on Vega.

The Vega MSE Porting Guide ( [Porting Media Source Extension (MSE) Players to Vega | Design and Develop Vega Apps](https://developer.amazon.com/docs/vega/0.23/mse-players.html) ) explicitly states as its first guideline:

│ “Replace XMLHttpRequest (XHR) objects with the Fetch API.”

The reason isSupported() returns false is that Vega’s JavaScript runtime supports the Fetch API but does not implement all the browser-specific APIs that Shaka’s support check looks for (constructible ReadableStream and new Response(‘’).body). The Fetch API itself works correctly for network requests - the check is a false negative on this platform.

The Vega Video Sample App’s approach of unregistering the default schemes and force-registering HttpFetchPlugin at APPLICATION priority is the sanctioned pattern. The XHR path is not the recommended networking path on Vega.

One additional note from the porting guide: “Do not use the ReadableStream interface in the Fetch API and use asynchronous full read.” This means fetch works on Vega without streaming support, which is sufficient for segment downloads.

Regarding your XHR/NaN bandwidth observation - this is consistent with XHR not being the supported path. The force-register pattern you found in the sample app is the correct solution.

References:

- Porting MSE Players to Vega ( [Porting Media Source Extension (MSE) Players to Vega | Design and Develop Vega Apps](https://developer.amazon.com/docs/vega/0.23/mse-players.html) )
- Vega Video Sample App - ShakaPlayer.ts  
( [vega-video-sample/src/w3cmedia/shakaplayer/ShakaPlayer.ts at main · AmazonAppDev/vega-video-sample · GitHub](https://github.com/AmazonAppDev/vega-video-sample/blob/main/src/w3cmedia/shakaplayer/ShakaPlayer.ts) )

Thanks for helping us improve the Vega platform.

Warm regards,  
Aishwarya

---

<div class="post-metadata">

**Author:** ![system](https://dhm3gbtzu79o6.cloudfront.net/user_avatar/community.amazondeveloper.com/system/32/5065_2.png) [@system](https://community.amazondeveloper.com/u/system)\
**Post date:** [July 22, 2026, 9:57pm UTC](https://community.amazondeveloper.com/t/should-apps-force-register-httpfetchplugin-when-issupported-returns-false/28715/5 "2026-07-22T21:57:36Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.