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

Hmm, it turns out that, to my surprise, browsers (Chrome at least) actually decompress files that have `Content-Encoding` when saving to disk (e.g. due to `Content-Disposition`). I always thought of `Content-Encoding` as being something that's not supposed to be handled until the data is to be consumed, unlike `Transfer-Encoding` which is clearly meant to be handled at the HTTP layer. It seems instead that browsers will automatically decode `Content-Encoding` in all cases I can think of.

I guess that this argues that, for the case of ServiceWorkers and `Response`s, my concern is moot. ServiceWorkers do not specify any means by which a `Response` can be sent back out on the network. It only exists within the browser, and within cache which is managed by the browser. So the `Content-Encoding` header from this point is just saying what encoding *was* used by the network transport (if the response ever crossed a network).

I'm working with a use case, though, where I'm trying to implement a proxy server which runs ServiceWorker-like code, so I actually need to figure out how to push a `Response` out over the network.

I suppose even for ServiceWorkers, the same question comes up with the `Request` object. What happens if I want to send a `Request` with a `Content-Encoding: gzip` body? Do I compressed the content before giving it to `fetch()`? Or does it do it for me?

-- 
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-325477889