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

[Section 4.6](https://fetch.spec.whatwg.org/#http-network-fetch) step 16.1.2 specifies that `Content-Encoding` is handled (responses are decoded) before `fetch()` completes, so the returned `Response` already has a decompressed body (but `response.headers.get('content-encoding')` still returns the original encoding).

This seems to create an inconsistency. What happens if I want to construct a `Response` manually that contains gzipped content? Say, for example, that I wish to construct a `Response` for the purpose of returning from a `FetchEvent` handler in a ServiceWorker. If I say:

    event.respondWith(new Response(data, {headers: {
      'Content-Type': 'text/plain',
      'Content-Encoding': 'gzip',
      'Content-Disposition': 'attachment; filename="file.txt.gz"'
    }}));

What happens? I can imagine a few possibilities:

* `data` should be uncompressed. The implementation will automatically compress it according to the `Content-Encoding` header, and the file downloaded will thus be compressed. (This is consistent, but weird, and it seemingly forces me to do a redundant decompress-compress round trip.)
* `data` should be compressed, to be consistent with the header. The implementation will not modify the bytes when downloading. (But this is inconsistent with `Response`s that came from calling `fetch()`!)
* This is an error. Specifying a `Content-Encoding` header here is incorrect. Consider `Content-Type: application/gzip` instead. (This seems generally unfortunate.)

(I'm posting this question against the fetch spec since it is where the `Response` class is specified, but the problem only seems to come up in the context of ServiceWorkers.)

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