Re: [whatwg/fetch] Constructing a Response with Content-Encoding? (#589)

I think for now I will specify that Response bodies are expected to be decompressed, and if you specify a Content-Encoding on an outgoing Response, then the system is expected to apply the encoding for you when writing out to network.

Meanwhile, I can do clever optimizations where I can detect if a Response body passes through verbatim, and avoid the compression round trip in that case.

There are two annoyances:
1. If someone embeds a static asset in their code, they can't embed it already-compressed. It will be compressed on-the-fly every time it is sent. Or, similarly, if someone, say, connected upstream using a non-HTTP protocol (WebSocket, perhaps) and pulled down compressed assets, they wouldn't be able to send those out in a Response without recompressing. These use cases are probably rare, though, and we can potentially provide a non-standard API to cover them if needed. Maybe `new Request()` could take an additional init option called `encodingAlreadyApplied` or something.
2. As I mentioned above, handing of Content-Encoding in Requests is inconsistent with Responses. But setting Content-Encoding on a request is relatively rare.

-- 
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/589#issuecomment-325725137