- From: Brad Isbell <notifications@github.com>
- Date: Fri, 28 Feb 2020 07:52:58 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/966/592574207@github.com>
> It does not seem "massive" to potentially place a forward proxy in place (e.g. a service like Caddy) for such services. I have yet to see a proxy such as this that handles all of the compatibility edge cases required for streaming media over HTTP. A lot of user-agent-specific modifications are needed. In any case, thank you for explaining in detail the compatibility issues you foresee. The context is very hepful. I just want to respond to this: > And I hate sad users 💔 We all do. Chrome isn't in isolation. The problematic hacks we have to put in place to work around simple things like being unable to make an HTTP request with a streaming request body lead to problems for users. I appreciate the efforts going into getting it right and building the most solid foundation possible. It's important however that the whole picture be considered. For an alternative example, when a browser developer says they won't implement `X` API for potential `Y` security/privacy concern... if the user is then just going to download some native binary and run it with root/admin permissions locally, then the security problem hasn't been resolved... it's just been made worse, and someone else's problem. In this case, I suppose we'll continue on with duplicating servers and bandwidth so that we can receive streams from browsers. I believe strongly in keeping web applications first-class citizens in the work that I do, but there is a real cost to it, in terms of complexity and resources, which trickles down to the user as less reliability and more money. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/966#issuecomment-592574207
Received on Friday, 28 February 2020 15:53:11 UTC