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.

Sign up for GitHub

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

Jump to bottom

🐛 BUG: wrangler pages dev, trying to start localhost:8788 crashes #3408

Closed
safaalai opened this issue Jun 6, 2023 · 9 comments
Closed

🐛 BUG: wrangler pages dev, trying to start localhost:8788 crashes #3408

safaalai opened this issue Jun 6, 2023 · 9 comments
Assignees
@mrbbot
Labels
bug Something that isn't working pages Relating to Pages

Comments

@safaalai
Copy link

safaalai commented Jun 6, 2023 •
edited
Loading

Which Cloudflare product(s) does this pertain to?

Pages, Wrangler

What version of Wrangler are you using?

3.0.1

What operating system are you using?

Mac OS 13.2.1

Describe the Bug

  1. I upgraded to Wrangler 3.0.1. Previously on wrangler 2.17.0 everything was working fine.
  2. \I start application with npx wrangler pages dev -- npm start
  3. npm start builds my files and starts application on localhost:33xx
  4. Try to start on localhost:8788 & I get a crash with the following message:
    *** Fatal uncaught kj::Exception: kj/compat/gzip.c++:80: failed: header = gzip decompression failed; ctx.msg = incorrect header check stack: 1031bf4d7 1031bf6a3 102ce3fbc 102ce3ce6 10444e7cf 10300d46d 102f51245 102f51462 104419d0d 102df1a0d 10441995f 104419cf3 102c9b45d 10441995f 10441adb4 10441b601 104418677 10294549b 1029451e4 1029451cc 10449b997 10449bac9 104499a9f 102937113 /usr/lib/dyld@630f

At this point browser tab is unresponsive and nothing else can be done. No part of my code was invoked before the crash.

My code does nothing with gzip. I believe gzip is invoked by the OS as it tries to decompress /usr/lib/dyld. dyld is a system file and cannot be deleted.

Everything was working fine with previous versions of Wrangler.
@safaalai safaalai added the bug Something that isn't working label Jun 6, 2023
@admah admah added the v3 label Jun 7, 2023
@safaalai
Copy link
Author

safaalai commented Jun 7, 2023

Tried Wrangler 3.1.0 and got same error message with different hex numbers.

@safaalai safaalai changed the title 🐛 BUG: wrangler pages dev, trying to start localhost:87 🐛 BUG: wrangler pages dev, trying to start localhost:8788 crashes Jun 7, 2023
@safaalai
Copy link
Author

safaalai commented Jun 7, 2023 •
edited
Loading

FYI: with Wrangler 2.17.0, as soon as I type localhost:8788, but before even pressing enter, there seems to be a prefetch and I get the following lines on the terminal:

GET / 200 OK (30.80ms)
GET /build/app.esm.js 200 OK (20.93ms)
GET /build/app.css 200 OK (11.91ms)
GET /build/app-globals-db86cf4d.js 200 OK (7.76ms)
GET /build/global-consts-7a63e241.js 200 OK (8.27ms)
GET /build/index-ec2903cb.js 200 OK (31.11ms)
GET /build/app-root.entry.js 200 OK (6.03ms)
GET /build/store-dc01520e.js 200 OK (8.01ms)
GET /build/person-3633208c.js 200 OK (11.53ms)

@safaalai
Copy link
Author

safaalai commented Jun 8, 2023 •
edited
Loading

RE: Github repository: https://github.com/safaalai/stencil-latest

To reproduce:

  1. npm init stencil app
  2. name the app when prompted & hit return
  3. cd to directory of the installed app
  4. npm install
  5. npm install @stencil/core@3
  6. In tsconfig.json add skipLibCheck under "compilerOptions"
  {
    "compilerOptions": {  
      ..... (lots of settings),
      "skipLibCheck": true
    },
    ....
  }
  1. npm start
    will start browser window and build app.
    verify that the app is working
  2. npm install wrangler
  3. npx wrangler pages dev -- npm start
  4. In the address bar of the browser, type localhost:8788

You should now see the crash

@cloudflare cloudflare deleted a comment from RZ7272 Jun 10, 2023
@penalosa penalosa added the pages Relating to Pages label Jun 15, 2023
@mrbbot
Copy link
Contributor

mrbbot commented Jun 26, 2023 •
edited
Loading

Hey! 👋 Apologies for the delayed response. Thank you for raising this and including a detailed reproduction. 😃 I'm able to reproduce this. It looks the Stencil dev sever is sending gzipped responses with the Content-Encoding: gzip header, but Miniflare is decompressing the responses whilst preserving this header before forwarding them onto the workerd dev server. Should be able to get this fixed. 👍

@mrbbot
Copy link
Contributor

mrbbot commented Jun 26, 2023

Did some more digging, and looks like we're blocked on nodejs/undici#2159 if we want to fix this for when Content-Encoding contains multiple encodings. Should be able to fix the single encoding case though while we wait for a release though. 👍

@safaalai
Copy link
Author

Did some more digging, and looks like we're blocked on nodejs/undici#2159 if we want to fix this for when Content-Encoding contains multiple encodings. Should be able to fix the single encoding case though while we wait for a release though. 👍

Thank you. This sounds great. Will look here to see when I can try it. Let me know if you need anything from me or suggest I try something.

mrbbot added a commit to cloudflare/miniflare that referenced this issue Jun 27, 2023
@mrbbot
Allow custom services to respond with Content-Encoding header
bfad6c4 
Previously, if the response from a custom service included a
`Content-Encoding` header, we would respond with decoded content to
`workerd` without removing the `Content-Encoding` header. This caused
`workerd` to try to decode already decoded content, resulting in an
error. This was particularly a problem with `wrangler pages dev`, as
upstream dev servers could very easily return gzipped content.

This change updates the `writeResponse()` function with code from
Miniflare 2, to re-encode the body before responding.

Note, due to a fixed but unreleased bug in `undici`
(nodejs/undici#2159), defining a custom service that directly proxies
somewhere else with `fetch()` like `wrangler pages dev` will fail, if
`Content-Encoding` contains multiple encodings.

Closes cloudflare/workers-sdk#3408
@mrbbot mrbbot mentioned this issue Jun 27, 2023
Merged
mrbbot added a commit to cloudflare/miniflare that referenced this issue Jun 27, 2023
@mrbbot
Allow custom services to respond with Content-Encoding header
1b7f77a 
Previously, if the response from a custom service included a
`Content-Encoding` header, we would respond with decoded content to
`workerd` without removing the `Content-Encoding` header. This caused
`workerd` to try to decode already decoded content, resulting in an
error. This was particularly a problem with `wrangler pages dev`, as
upstream dev servers could very easily return gzipped content.

This change updates the `writeResponse()` function with code from
Miniflare 2, to re-encode the body before responding.

Note, due to a fixed but unreleased bug in `undici`
(nodejs/undici#2159), defining a custom service that directly proxies
somewhere else with `fetch()` like `wrangler pages dev` will fail, if
`Content-Encoding` contains multiple encodings.

Closes cloudflare/workers-sdk#3408
@safaalai
Copy link
Author

safaalai commented Jul 7, 2023

This crash no longer happens as of 3.1.2. Please let me know if you wish me to close the bug.

@TimPetricola
Copy link

I had the same issue and I confirm it's fixed with 3.1.2. Thanks a lot!

@lrapoport-cf
Copy link
Contributor

looks like this is no longer an issue so closing this out :) please feel free to re-open if the issue comes up again!

mrbbot added a commit that referenced this issue Oct 31, 2023
@mrbbot
Allow custom services to respond with Content-Encoding header
0a58ba2 
Previously, if the response from a custom service included a
`Content-Encoding` header, we would respond with decoded content to
`workerd` without removing the `Content-Encoding` header. This caused
`workerd` to try to decode already decoded content, resulting in an
error. This was particularly a problem with `wrangler pages dev`, as
upstream dev servers could very easily return gzipped content.

This change updates the `writeResponse()` function with code from
Miniflare 2, to re-encode the body before responding.

Note, due to a fixed but unreleased bug in `undici`
(nodejs/undici#2159), defining a custom service that directly proxies
somewhere else with `fetch()` like `wrangler pages dev` will fail, if
`Content-Encoding` contains multiple encodings.

Closes #3408
mrbbot added a commit that referenced this issue Nov 1, 2023
@mrbbot
Allow custom services to respond with Content-Encoding header
02ab9a1 
Previously, if the response from a custom service included a
`Content-Encoding` header, we would respond with decoded content to
`workerd` without removing the `Content-Encoding` header. This caused
`workerd` to try to decode already decoded content, resulting in an
error. This was particularly a problem with `wrangler pages dev`, as
upstream dev servers could very easily return gzipped content.

This change updates the `writeResponse()` function with code from
Miniflare 2, to re-encode the body before responding.

Note, due to a fixed but unreleased bug in `undici`
(nodejs/undici#2159), defining a custom service that directly proxies
somewhere else with `fetch()` like `wrangler pages dev` will fail, if
`Content-Encoding` contains multiple encodings.

Closes #3408
mrbbot added a commit that referenced this issue Nov 1, 2023
@mrbbot
Allow custom services to respond with Content-Encoding header
6413981 
Previously, if the response from a custom service included a
`Content-Encoding` header, we would respond with decoded content to
`workerd` without removing the `Content-Encoding` header. This caused
`workerd` to try to decode already decoded content, resulting in an
error. This was particularly a problem with `wrangler pages dev`, as
upstream dev servers could very easily return gzipped content.

This change updates the `writeResponse()` function with code from
Miniflare 2, to re-encode the body before responding.

Note, due to a fixed but unreleased bug in `undici`
(nodejs/undici#2159), defining a custom service that directly proxies
somewhere else with `fetch()` like `wrangler pages dev` will fail, if
`Content-Encoding` contains multiple encodings.

Closes #3408
mrbbot added a commit that referenced this issue Nov 1, 2023
@mrbbot
Allow custom services to respond with Content-Encoding header
93bf8ba 
Previously, if the response from a custom service included a
`Content-Encoding` header, we would respond with decoded content to
`workerd` without removing the `Content-Encoding` header. This caused
`workerd` to try to decode already decoded content, resulting in an
error. This was particularly a problem with `wrangler pages dev`, as
upstream dev servers could very easily return gzipped content.

This change updates the `writeResponse()` function with code from
Miniflare 2, to re-encode the body before responding.

Note, due to a fixed but unreleased bug in `undici`
(nodejs/undici#2159), defining a custom service that directly proxies
somewhere else with `fetch()` like `wrangler pages dev` will fail, if
`Content-Encoding` contains multiple encodings.

Closes #3408
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mrbbot mrbbot

Labels
bug Something that isn't working pages Relating to Pages
Projects
workers-sdk
Archived in project
Milestone
No milestone
Development

No branches or pull requests
6 participants
@TimPetricola @admah @mrbbot @penalosa @safaalai @lrapoport-cf