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

Panic on Deno.server with a HEAD request #17737

Closed
ntkoopman opened this issue Feb 11, 2023 · 0 comments · Fixed by #17740
Closed

Panic on Deno.server with a HEAD request #17737

ntkoopman opened this issue Feb 11, 2023 · 0 comments · Fixed by #17740

Comments

@ntkoopman
Copy link

ntkoopman commented Feb 11, 2023 •
edited
Loading

Using the following code:

async function handler() {
  let response = await fetch('https://deno.land')
  let body = await response.text();
  return new Response(body)
}

Deno.serve(handler, { hostname: '127.0.0.1', port: 4500 });

Performing a HEAD request using:

curl http://127.0.0.1:4500 -I

Will result in Deno crashing:

============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: linux x86_64
Version: 1.30.3
Args: ["deno", "--unstable", "run", "-A", "test.ts"]

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', ext/flash/lib.rs:160:46
stack backtrace:
   0:     0x55959369a26c - <unknown>
   1:     0x559592bca1fe - <unknown>
   2:     0x5595936668f4 - <unknown>
   3:     0x55959369d10f - <unknown>
   4:     0x55959369cd0f - <unknown>
   5:     0x55959369ca21 - <unknown>
   6:     0x559592b5932c - <unknown>
   7:     0x55959369dac0 - <unknown>
   8:     0x55959369d824 - <unknown>
   9:     0x55959369d7bc - <unknown>
  10:     0x55959369d791 - <unknown>
  11:     0x559592753502 - <unknown>
  12:     0x5595927535fc - <unknown>
  13:     0x559592e7733b - <unknown>
  14:     0x559592e76116 - <unknown>
  15:     0x559592e75283 - <unknown>
  16:     0x559594439185 - <unknown>
  17:     0x559594438576 - <unknown>
  18:     0x5595942d0c38 - <unknown>
@kamilogorek kamilogorek mentioned this issue Feb 11, 2023
Merged
littledivy pushed a commit that referenced this issue Feb 12, 2023
@kamilogorek
fix(ext/flash): Always send correct number of bytes when handling HEA…
d4e5a29 
…D requests (#17740)

This was not caught in the previous test case, as the response body was
smaller than the size of `HEAD` response.
This made `nwritten < responseLen` check in `writeFixedResponse` to
fail, and not trigger `op_flash_respond_async` as a result.

When the response body is larger than the `HEAD` though, as in the
updated test case (`HEAD` i 120 bytes, where our response is 300 bytes),
it would think that we still have something to send, and effectively
panic, as `op_flash_respond` already removed the request from the pool.

This change, makes the `handleResponse` function always calculate the
number of bytes to transmit when `HEAD` request is encountered.
Effectively ignoring `Content-Length` of the body, but still setting it
correctly in the request header itself.

Fixes #17737
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(flash): Always send correct number of bytes when handling HEAD requests
1 participant
@ntkoopman