cloudflare / cloudflare/workerd

Content-Encoding header not updated appropriately

Open
#5,112 1 comment 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.