Andreas Farre

The resoning here is that we should not produce arbitrary output, and that includes the file output from -MF.

> One thing that needs to be checked is whether or not dependency files are generated on cache hits. I'm worried about #111 that I think is related to this...

There's also a sniff happening [here](https://searchfox.org/mozilla-central/rev/8f09f6a6ff0d8b6ea75a1e1279a06ba02479578c/netwerk/protocol/http/nsHttpChannel.cpp#1601-1626), if `LOAD_CALL_CONTENT_SNIFFERS` is set, which it is in [nsDocShellLoadState::CalculateChannelLoadFlags](https://searchfox.org/mozilla-central/rev/8f09f6a6ff0d8b6ea75a1e1279a06ba02479578c/docshell/base/nsDocShellLoadState.cpp#1116-1118), but I'm not sure if we're hitting that path, I'd have to check. And I...

Maybe there's a compromise here, if we say that we sniff the first part and block based on that and if the subresource changes type, then we just allow it....

There also seems to be instances of sites streaming media, where streaming doesn't start at the beginning, which complicates things. C.f. [bugzilla 1827684](https://bugzilla.mozilla.org/show_bug.cgi?id=1827684)

To some extent we'd need to clear headers. And it is unfortunate, I'd much rather block. But we keep running into these cases of scripts breaking due to ORB blocks...

@otherdaniel, just a heads up to issues you might run into.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1823877 we're trying to make sure that filtered responses are filtered in such a way that we don't leak the filtered data. With ORB and Window.fetch+no-cors we have to...

[FetchEvent.respondWith](https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/respondWith)'s behavior for "no-cors" then becomes a thing to discuss I guess. In the ideal case I mean, since that is specified to have the behavior for "no-cors" fetches pre-ORB....

And I should note that: - I tried to make a PR, but it felt like I'd make a mess of things. I'm happy to do it if I get...