This is the release commit being forwarded back to main for 2.2.7
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Fixes#20198
The Web Crypto implementation has been artificially limiting `ECDSA` to
only the “recommended” curve/hash pairs (`P‑256/SHA‑256` and
`P‑384/SHA‑384`). The underlying `ring` APIs enforced those pairs, so
any attempt to verify signatures produced with different digests (e.g.
`P‑384` with `SHA‑256`) failed with a “Not implemented” error.
This PR rewires the ECDSA sign/verify path to use RustCrypto’s `ecdsa`
crate instead of `ring`, computes digests separately, and uses the
prehash signing/verifying API so that any `sha1`, `sha256`, `sha384` or
`sha512` can be used with either curve. The JS `SubtleCrypto` bindings
were updated to drop the hard coded checks, and a new unit test
exercises `P‑384 + SHA‑256` to ensure non‑matching combos now round
trip.
---------
Signed-off-by: Gene Parmesan Thomas <201852096+gopoto@users.noreply.github.com>
Signed-off-by: gopoto <201852096+gopoto@users.noreply.github.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Deno.serve `Request` abort signals are aborted by default even when it
is finished successfully. This PR gates this behavior behind the
"legacy_abort" which is the default right now.
Turning the `no_legacy_abort` runtime option on is a **breaking change**
and will only abort request signals when there is a failure, thereby
cannot be used to determine if the request finished. This aligns with
`fetch` API.
Ref https://github.com/denoland/deno/issues/27005
NOTE: Commit 27363d389 was incorrectly landed in main before the release
completed and is not included in v2.2.5. The official v2.2.5 release was made
from the v2.2 branch.
`import.meta.log` enables basic log filtering through
`env_logger`/`DENO_LOG`. Log levels are supported, and filenames can
also be used. for example: `DENO_LOG=ext:deno_http::00_serve.ts=warn`
This pr explicitly enables the `sysinfoapi` feature flag on `winapi` in
`deno_os`, so that `deno_os` and other deno crates that rely on it can
be built independently outside of the workspace on Windows.
Matches Node.js `http.STATUS_CODES` values now. Deno is currently
exporting an enum directly, which 1) adds keys like `BadRequest` and 2)
ships the status-text strings as non-space-delimited values (eg,
`'BadRequest`` instead of `'Bad Request'`)
Signed-off-by: Luke Edwards <luke.edwards05@gmail.com>
Currently, there is no way to implement `FetchPermissions` without
importing `FsError` from `deno_fs` directly. This PR aims to re-export
the `FsError` from `deno_fetch` itself to allow it.
results on my machine (Macbook pro w/ M3 Max)
canary (hello world):
```
❯ oha -c 125 -n 4000000 --no-tui --disable-compression http://localhost:8000
Summary:
Success rate: 100.00%
Total: 31.0160 secs
Slowest: 0.0083 secs
Fastest: 0.0005 secs
Average: 0.0010 secs
Requests/sec: 128965.6454
Total data: 49.59 MiB
Size/request: 13 B
Size/sec: 1.60 MiB
```
this PR (hello world):
```
❯ oha -c 125 -n 4000000 --no-tui --disable-compression http://localhost:8000
Summary:
Success rate: 100.00%
Total: 28.4050 secs
Slowest: 0.0085 secs
Fastest: 0.0001 secs
Average: 0.0009 secs
Requests/sec: 140820.2060
Total data: 49.59 MiB
Size/request: 13 B
Size/sec: 1.75 MiB
```
---
Two changes here:
- use `opt-level` 3 for some of hyper's deps, since profile overrides
are not transitive
- As noted in the [cargo
reference](https://doc.rust-lang.org/cargo/reference/profiles.html#overrides-and-generics)
generic functions _may_ be optimized at the opt-level of the
_instantiating_ crate, rather than the defining crate. So currently it's
possible that some of the functions in `deno_http` are being compiled at
a lower optimization level. This PR ensures the generics are
instantiated in `deno_http`, which theoretically should guarantee they
actually use opt-level 3.
To allow embedders to still provide a custom property extractor, I put
this behind a feature flag.
