Completely virtual webRequest

Lately I’ve been looking for a way to create a stream as a URL that is usable in a .src. I posted more generally over on StackOverflow, where a helpful individual pointed out you could use a ServiceWorker + FetchEvent.respondWith + a ReadableStream to make this work. While that is a clever solution, I can’t use directly use ServiceWorkers in the plugin. I suppose it would be possible to do this in a content script somehow but that would do bad things for the performance of the plugin as whole - which is what I’m trying to improve.

So, another potential option would be to either:

  1. Hook a virtual page like an extension page also using webRequest and pretend it is a stream. Unfortunately, only http/https and ws/wss are allowable for webRequest so I don’t think this is possible?
  2. Somehow create a webRequest that never actually reaches out to the web with an invalid address and then write to a FilterStream. Unfortunately, I don’t think this is possible either.

In the same vein as #2 I could open a request to some arbitrary HTTP address and then wholly rewrite the stream but that seems bad as it forces an outbound call and makes my extension dependent on some arbitrary address.

Surely there’s some way to make a webRequest - either by design or by hack - that can be completely virtual?

Couldn’t you just pass a readable stream that you made yourself (and can thus write to) as blob?

Well in order for it to be a Blob, I have to have the whole thing at one shot, right? I’d like to do this in a streaming fashion. Ideally I could use something like e.g. a MediaSource but I’m looking for a generalized streaming solution. Does that make sense @freaktechnik?

Well, I made an interesting discovery. I expected that if I put a truly bogus address in such as “http://non-existent-host/test.mp4” that webRequest would simply fire “onErrorOcurred” and that I wouldn’t be able to do anything else.
However, what actually happened is that I could see at least down to webRequest.onHeadersReceived fires, such that I can successfully create and return a value via the StreamFilter.
While this behavior is highly beneficial for me - as it enables essentially virtual streams without hitting a “true” external address - I must say that I was bit puzzled that it allows this. I’m on Firefox 72.0.2. Can anyone from the dev team comment on if this is expected behavior? I’d like to make sure I’m not simply exploiting a forgotten loophole but rather using an expected feature if I proceed further with this…