Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] No way to return pre-compressed data with Content-Encoding from worker-rs due to missing encodeBody option #567

Closed
1 task done
himikof opened this issue May 4, 2024 · 0 comments · Fixed by #568

Comments

@himikof
Copy link

himikof commented May 4, 2024

Is there an existing issue for this?

  • I have searched the existing issues

What version of workers-rs are you using?

0.2.0

What version of wrangler are you using?

3.53.0

Describe the bug

According to https://stackoverflow.com/a/64849685 and encodeBody documentation, the only way to return already-gzipped data from worker (without decompressing and compressing again) with Content-Encoding: gzip set (for the browser to decompress it automatically) is to set the encodeBody Response init option to "manual":

// Make a new response with the same body but using manual encoding.
resp = new Response(resp.body, {
  status: resp.status,
  headers: resp.headers,
  encodeBody: "manual"
});

// Modify headers and return.
resp.headers.set("Content-Encoding", "gzip");
return resp;

If encodeBody: "manual" is missing, Worker runtime will silently compress the body again, returning gzip-in-gzip data to the browser.

I have failed to find any reasonable way to set this option in worker-rs, because it can only be passed through ResponseInit object, and the current worker code:

  1. has no support for passing anything apart from status, headers and websocket through ResponseInit;
  2. has no support for using custom ResponseInit instances;
  3. constructs the ResponseInit object too late (after the fetch handler has completed processing), so the handler cannot customize it further.

Also, the encodeBody documentation is a bit confusing: it makes it seem like encodeBody is a property on Response, but according to my reading of workerd code, it can be only passed during Response construction through init (ResponseInit.encodeBody property, essentially), and is not exposed on the Response object in any way.

Steps To Reproduce

No response

kflansburg added a commit that referenced this issue May 19, 2024
* Add `encodeBody` and `cf` to ResponseInit. Adopt builder pattern.

Closes #567

* Refine builder pattern

* address comments

* Response.clone, test, http extensions

* Do not check content-type in Response.json

Closes #577
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant