Re: [whatwg/fetch] Request body streams should use chunked encoding (#966)

> 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