cloudflare / cloudflare/workerd
Content-Encoding header not updated appropriately
- Dominant language
- C++
- Stars
- 8.7k
- Forks
- 739
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 174
Description
Repro:
```js
export default {
async fetch(req, env) {
const resp = await fetch('http://www.cloudflare.com', {
headers: {
'accept-encoding': 'gzip'
}
});
const headers = new Headers();
headers.set('x-content-encoding', resp.headers.get('content-encoding'));
let length = 0;
const dec = new TextDecoder();
for await (const chunk of resp.body) {
length += chunk.length;
console.log(dec.decode(chunk, { stream: true }) );
}
console.log(dec.decode() );
headers.set('x-decompressed-length', length);
return new Response("Hello World\n", { headers } );
}
};
```
When workerd decompresses the body, it still reports the `content-type` as being `gzip` when it should be removing the coding from the header.
In contrast, if `accept-encoding` is changed to `br`, the data read is still compressed and the `content-encoding` header is still `br`...
Which means users cannot rely on the `content-encoding` header as signal, the data still may or may still be encoded.
this is not an issue in production. the faulty handling here is within workerd.
Contributor guide
Assessment
This issue has not been assessed yet.