It’s okay, I think in the future if we have bounties like this the developer should meet with the team to discuss first, or have someone sign off on the design in the proposed issue. Perhaps I should have been more proactive in gathering opinions from the team.
It should work fine in production as long as you use raw.ic0.app, which is what I’ve been doing for my audio anyway (just for the audio URLs, you can still serve a certified app from ic0.app, but any audio or video URLs would need to be served from raw.ic0.app). It’s a trade-off but it’s working just great for my audio now (you just have to download the file in your podcast player), and I don’t think the security is that necessary for streaming audio and video.
The same types of issues with streaming and certification are discussed here: Is it possible to make raw.ic0.app calls from ic0.app and reverse?
I’d much rather just use raw.ic0.app for audio and video files and have the much better streaming experience than wait for certification to get figured out.
Not to mention I foresee canisters wanting to provide their own http response headers, and I’m hoping we can allow those. I think it’s quite likely someone will run into this limitation in the future and why not address it sooner rather than later.