| Age | Commit message (Collapse) | Author |
|---|
|
Add a new op to use in `reader.readAsBinaryString(blob)`.
```
File API binary string: 400b 35.12 µs/iter (21.93 µs … 3.27 ms) 31.87 µs 131.95 µs 217.63 µs
File API binary string: 4kb 46.49 µs/iter (29.36 µs … 4.42 ms) 42.5 µs 122.48 µs 155.1 µs
File API binary string: 2.2mb 4.17 ms/iter (1.75 ms … 8.54 ms) 5.48 ms 7.39 ms 8.54 ms
```
**main**
```
benchmark time (avg) (min … max) p75 p99 p995
--------------------------------------------------------------------- -----------------------------
File API binary string: 400b 56.17 µs/iter (43.09 µs … 784.52 µs) 49.6 µs 177.18 µs 241.23 µs
File API binary string: 4kb 277.2 µs/iter (240.29 µs … 1.84 ms) 269.87 µs 649.79 µs 774.46 µs
File API binary string: 2.2mb 180.03 ms/iter (173.32 ms … 194.35 ms) 182.54 ms 194.35 ms 194.35 ms
```
It can also handle bigger files, when encoding a 200mb file, main
crashes with OOM
```
<--- Last few GCs --->
[132677:0x560504676550] 5012 ms: Scavenge 417.3 (434.6) -> 401.8 (434.6) MB, 0.1 / 0.0 ms (average mu = 0.824, current mu = 0.825) allocation failure;
[132677:0x560504676550] 5038 ms: Scavenge 417.3 (434.6) -> 401.8 (434.6) MB, 0.1 / 0.0 ms (average mu = 0.824, current mu = 0.825) allocation failure;
[132677:0x560504676550] 5064 ms: Scavenge 417.3 (434.6) -> 401.8 (434.6) MB, 0.1 / 0.0 ms (average mu = 0.824, current mu = 0.825) allocation failure;
```
|
|
Add a fast path for consuming the body of cloned `Request`/`Response`,
which is very common specially when using `cache` API.
|
|
This commit adds a `reuseAddress` option for UDP sockets. When this
option is enabled, one can listen on an address even though it is
already being listened on from a different process or thread. The new
socket will steal the address from the existing socket.
On Windows and Linux this uses the `SO_REUSEADDR` option, while on other
Unixes this is done with `SO_REUSEPORT`.
This behavior aligns with what libuv does.
TCP sockets still unconditionally set the `SO_REUSEADDR` flag - this
behavior matches Node.js and Go. This PR does not change this behaviour.
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
When listening on a UNIX socket path, Deno currently tries to unlink
this path prior to actually listening. The implementation of this
behaviour is VERY racy, involves 2 additional syscalls, and does not
match the behaviour of any other runtime (Node.js, Go, Rust, etc).
This commit removes this behaviour. If a user wants to listen on an
existing socket, they must now unlink the file themselves prior to
listening.
This change in behaviour only impacts --unstable APIs, so it is not
a breaking change.
|
|
[`crypto.getRandomValues`](https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues)
does not return a Promise.
|
|
original connection is captured elsewhere (#16242)
This commit removes the calls to `expect()` on `std::rc::Rc`, which caused
Deno to panic under certain situations. We now return an error if `Rc`
is referenced by other variables.
Fixes #9360
Fixes #13345
Fixes #13926
Fixes #16241
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
This change adds `windowsRawArguments` to `SpawnOptions`. The option enables
skipping the default quoting and escaping while creating the command on
windows.
The option works in a similar way as `windowsVerbatimArguments` in
child_process.spawn options in Node.js, and is necessary for simulating
it in `std/node`.
closes #8852
|
|
|
|
fixes #16180
`HMAC`'s `get key length` `op` uses the hash function's block size, not
output size.
refs
https://github.com/cloudflare/workerd/issues/68#issuecomment-1271189657
|
|
This PR fixes invalid header parsing which is flaky because `g` flag is
being used in the regex, which keeps track of `lastIndex`
```javascript
try {
new Headers([["x", "\u0000x"]]); // error
} catch(e) {}
new Headers([["x", "\u0000x"]]); // no error
```
This issue affects `Response` & `Request` constructors as well
|
|
fix https://github.com/denoland/deno/issues/16202
|
|
This commit introduces two new buffer wrapper types to `deno_core`. The
main benefit of these new wrappers is that they can wrap a number of
different underlying buffer types. This allows for a more flexible read
and write API on resources that will require less copying of data
between different buffer representations.
- `BufView` is a read-only view onto a buffer. It can be backed by
`ZeroCopyBuf`, `Vec<u8>`, and `bytes::Bytes`.
- `BufViewMut` is a read-write view onto a buffer. It can be cheaply
converted into a `BufView`. It can be backed by `ZeroCopyBuf` or
`Vec<u8>`.
Both new buffer views have a cursor. This means that the start point of
the view can be constrained to write / read from just a slice of the
view. Only the start point of the slice can be adjusted. The end point
is fixed. To adjust the end point, the underlying buffer needs to be
truncated.
Readable resources have been changed to better cater to resources that
do not support BYOB reads. The basic `read` method now returns a
`BufView` instead of taking a `ZeroCopyBuf` to fill. This allows the
operation to return buffers that the resource has already allocated,
instead of forcing the caller to allocate the buffer. BYOB reads are
still very useful for resources that support them, so a new `read_byob`
method has been added that takes a `BufViewMut` to fill. `op_read`
attempts to use `read_byob` if the resource supports it, which falls
back to `read` and performs an additional copy if it does not. For
Rust->JS reads this change should have no impact, but for Rust->Rust
reads, this allows the caller to avoid an additional copy in many
scenarios. This combined with the support for `BufView` to be backed by
`bytes::Bytes` allows us to avoid one data copy when piping from a
`fetch` response into an `ext/http` response.
Writable resources have been changed to take a `BufView` instead of a
`ZeroCopyBuf` as an argument. This allows for less copying of data in
certain scenarios, as described above. Additionally a new
`Resource::write_all` method has been added that takes a `BufView` and
continually attempts to write the resource until the entire buffer has
been written. Certain resources like files can override this method to
provide a more efficient `write_all` implementation.
|
|
|
|
Currently Content-Length is sent when the status code is 204. However,
according to the spec, this should not be sent.
Modify the if statement below to prevent the Content-Length from being
sent.
|
|
This commit adds a fast path to `Request` and `Response` that
make consuming request bodies much faster when using `Body#text`,
`Body#arrayBuffer`, and `Body#blob`, if the body is a FastStream.
Because the response bodies for `fetch` are FastStream, this speeds up
consuming `fetch` response bodies significantly.
|
|
This PR updates RSA key import/export to a state which is interoperable
with other implementations.
For RSA the only OID in and out is `rsaEncryption`.
For EC the only OID in and out is `id-ecpublickey` (fixed in #16152).
see https://github.com/w3c/webcrypto/issues/307#issuecomment-995813032
see https://github.com/w3c/webcrypto/issues/307
see https://github.com/w3c/webcrypto/pull/305
see https://github.com/nodejs/node/pull/42816
|
|
|
|
Fixes #16047
|
|
|
|
Co-authored-by: Jason <m.jason.liu@outlook.com>
|
|
|
|
This fixes a bug where `Body#bodyUsed` incorrectly returns `false`
for a body that has actually already been consumed, after `Body#body`
is called.
|
|
|
|
|
|
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
This fast path prevents repeated allocations when receiving a fetch body with a known size.
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
|
|
(#15935)
|
|
|
|
|
|
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
|
|
|
directories (#15949)
|
|
|
|
|
|
This commit makes error objects more resistant to
prototype tampering.
This bug was found when updating the deno_std Node compatibility
layer to Node 18. The Node test 'parallel/test-assert-fail.js'
was breaking std's assertion library.
Refs: https://github.com/denoland/deno_std/pull/2585
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Nayeem Rahman <nayeemrmn99@gmail.com>
|
|
|
|
|
|
This commit fixes "Deno.serve()" API by making sure that
205 and 304 responses end with "\r\n\r\n".
|
|
|
