This commit stabilizes Node-API, the "--unstable" flag is no longer
required to load native extensions. "--allow-ffi" permission is still
required to load them.
Fixes https://github.com/denoland/deno/issues/17761
Tugstenite already sends a pong for a recieved ping. This automatically
happens when the socket read is being driven. From
https://github.com/snapview/tokio-tungstenite/issues/88
> You need to read from the read-side of the socket so that it
receives/handles pings, and on the next write it would then send the
corresponding pong.
Here's the source:
e1033afd95/src/protocol/mod.rs (L374-L380)
```rust
// Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in
// response, unless it already received a Close frame. It SHOULD
// respond with Pong frame as soon as is practical. (RFC 6455)
if let Some(pong) = self.pong.take() {
trace!("Sending pong reply");
self.send_one_frame(stream, pong)?;
}
```
WIth this patch, all Autobahn tests from 1-8 pass. Fixed cases: 2.1,
2.2, 2.3, 2.4, 2.6, 2.9, 2.10, 2.11, 5.6, 5.7, 5.8, 5.19, 5.20
To run the test yourself, follow
https://www.notion.so/denolandinc/Autobahn-WebSocket-testsuite-723a86f450ce4823b4ef9cb3dc4c7869?pvs=4
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 https://github.com/denoland/deno/issues/17737
This commit moves some code around from "cli/node/mod.rs" to
"ext/node". Additionally "ext/node" was changed to factor out
"ops.rs" and "polyfill.rs" modules.
This commit does preparatory work to allow snapshotting Node.js
compatibility layer, that currently lives in `std/node`. The logic was
changed to allow loading some modules from the snapshot and
some from the remote URL.
Additionally "module_es_shim.js" that provides exports for "node:module"
is now snapshotted.
This PR refactors all internal js files (except core) to be written as
ES modules.
`__bootstrap`has been mostly replaced with static imports in form in
`internal:[path to file from repo root]`.
To specify if files are ESM, an `esm` method has been added to
`Extension`, similar to the `js` method.
A new ModuleLoader called `InternalModuleLoader` has been added to
enable the loading of internal specifiers, which is used in all
situations except when a snapshot is only loaded, and not a new one is
created from it.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Currently fast ops will always check for the alignment of a TypedArray
when getting a slice out of them. A match is then done to ensure that
some slice was received and if not a fallback will be requested.
For Uint8Arrays (and WasmMemory which is equivalent to a Uint8Array) the
alignment will always be okay. Rust probably optimises this away for the
most part (since the Uint8Array check is `x % 1 != 0`), but what it
cannot optimise away is the fast ops path's request for fallback options
parameter.
The extra parameter's cost is likely negligible but V8 will need to
check if a fallback was requested and prepare the fallback call just in
case it was. In the future the lack of a fallback may also enable V8 to
much better optimise the result handling.
For V8 created buffers, it seems like all buffers are actually always
guaranteed to be properly aligned: All buffers seem to always be created
8-byte aligned, and creating a 32 bit array or 64 bit array with a
non-aligned offset from an ArrayBuffer is not allowed. Unfortunately,
Deno FFI cannot give the same guarantees, and it is actually possible
for eg. 32 bit arrays to be created unaligned using it. These arrays
work fine (at least on Linux) so it seems like this is not illegal, it
just means that we cannot remove the alignment checking for 32 bit
arrays.
This patch makes `NativeType` to `libffi::middle::Type` conversion
failliable and w.t disallows struct with empty fields. libffi does not
handle "empty" struct because they don't exist in C (or Rust).
Fixes #17481
Bump the rsa crate to 0.7.0
The API for the `rsa` crate has changed significantly, but I have
verified that tests continue to pass throughout this update.
I mistakenly held on to a RefCell's borrow for the whole time of
iteration, but since these counters can be refed/unrefed from any
thread that is a mistake.
Updated third_party dlint to v0.37.0 for GitHub Actions. This PR
includes following changes:
* fix(prefer-primordials): Stop using array pattern assignments
* fix(prefer-primordials): Stop using global intrinsics except for
`SharedArrayBuffer`
* feat(guard-for-in): Apply new guard-for-in rule
If the JS handler gets a POST, PUT, or PATCH request, but doesn't
`await` the body, deno would panic because it will try to read the body
even though the request has already been handled.
Not sure how/where to test this case, so I could use some help with
that.
