The Web IDL conversion to `BufferSource` and similar types shouldn't
check whether the buffer is detached.
In the case of `TextDecoder`, our implementation would still throw after
the Web IDL conversions because we're creating a new `Uint8Array` from
the buffer source's buffer, which throws if it's detached. This change
also fixes this bug.
The implementation of `TextDecoder` had a bug where it was copying the
input data in every case. This change removes that copy in
non-`SharedArrayBuffer` cases.
Since passing a shared buffer source to Rust would fail, this copy of
the input data was making `TextDecoder` work in cases where the input
is shared. In order to avoid a breaking change, the copy is retained in
those cases.
Closes #11882
BREAKING CHANGE: Previously when `--location` was set, the unique storage key was derived from the the URL of the location instead of just the origin. This change correctly uses just the origin. This may cause previously persisted storage to change its key and data to not be available with the same location as before.
A `handshake()` method was added that returns when the TLS handshake is
complete. The `TlsListener` and `TlsConn` interfaces were added to
accomodate this new method.
Closes: #11759.
`fetch()` and client-side websocket used to support HTTP/2, but this
regressed in #11491. This patch reenables it by explicitly adding `h2`
and `http/1.1` to the list of ALPN protocols on the HTTP and websocket
clients.
A bug was fixed that could cause a hang when a method was
called on a TlsConn object that had thrown an exception earlier.
Additionally, a bug was fixed that caused TlsConn.write() to not
completely flush large buffers (>64kB) to the socket.
The public `TlsConn.handshake()` API is scheduled for inclusion in the
next minor release. See https://github.com/denoland/deno/pull/12467.
Currently all async ops are polled lazily, which means that op
initialization code is postponed until control is yielded to the event
loop. This has some weird consequences, e.g.
```js
let listener = Deno.listen(...);
let conn_promise = listener.accept();
listener.close();
// `BadResource` is thrown. A reasonable error would be `Interrupted`.
let conn = await conn_promise;
```
JavaScript promises are expected to be eagerly evaluated. This patch
makes ops actually do that.
GET/HEAD requests can't have bodies according to `fetch` spec. This
commit changes the HTTP server to hide request bodies for requests with
GET or HEAD methods.
WebAssembly modules compiled through `WebAssembly.compile()` and similar
non-streaming APIs don't have a URL associated to them, because they
have been compiled from a buffer source. In stack traces, V8 will use
a URL such as `wasm://wasm/d1c677ea`, with a hash of the module.
However, wasm modules compiled through streaming APIs, like
`WebAssembly.compileStreaming()`, do have a known URL, which can be
obtained from the `Response` object passed into the streaming APIs. And
as per the developer-facing display conventions in the WebAssembly
Web API spec, this URL should be used in stack traces. This change
implements that.
This commit adds support for passing buffer arguments across
FFI boundary.
Co-authored-by: eliassjogreen <eliassjogreen1@gmail.com>
Co-authored-by: Bert Belder <bertbelder@gmail.com>
These are confusing. They say they are "for users that don't care about
permissions", but that isn't correct. `NoTimersPermissions` disables
permissions instead of enabling them.
I would argue that implementors should decide what permissions they want
themselves, and not take our opinionated permissions struct.
This adds support for using in memory CA certificates for
`Deno.startTLS`, `Deno.connectTLS` and `Deno.createHttpClient`.
`certFile` is deprecated in `startTls` and `connectTls`, and removed
from `Deno.createHttpClient`.
Avoid "blob:" prefix check on requests built in the http module since those can never be blob objects
Reduces cost of `newInnerRequest()` from 20ms to 0.1ms in my profiled run on ~2.5M reqs
Not useful to have the defaults externally defined when they're only used in `newInnerResponse()`. Also match order in `newInnerResponse()` and `cloneInnerResponse`
Our oneshot receiver in `HyperService::call` would unwrap and panic, the `.await` on the oneshot receiver happens when the sender is dropped.
The sender is dropped in `op_http_response` because:
1. We take `ResponseSenderResource`
2. Then get `ConnResource` and early exit on failure (conn already closed)
3. The taken sender then gets dropped in this early exit before any response is sent over the channel
Fallbacking to returning a dummy response to hyper seems to be a fine quickfix
Check for expected headers more rigorously and check that it's a
HTTP/1.1 GET request. The logic mirrors what Deno Deploy and the
tungstenite crate do.
The presence of "Sec-Websocket-Version: 13" is now also enforced.
I don't expect that to break anything: conforming clients already
send it and tungstenite can't talk to older clients anyway.
The new code is more efficient due to heap-allocating less and aligns
more closely with the checks in ext/http/01_http.js now.
* perf(ext/fetch): skip USVString webidl conv on string constructor
* Rename webidl convert to RequestInfo_DOMString
To disambiguate and hint that it normalizes to DOMString instead of USVString since DOMString => USVString is handled by `op_url_parse` when calling `new URL(...)`
Default to None if UnsafelyIgnoreCertificateErrors is not present in the
OpState.
Embedders may not have a need for restricting outgoing TLS connections
and having them hunt through the source code for the magic incantation
that makes the borrow panics go away, is less user friendly.
and all its subclasses including `AbortSignal` ...
Instead of storing associated data in a global `WeakMap` we store them as private attributes (via a Symbol) on the object instances
Async WebAssembly compilation was implemented by adding two
bindings: `set_wasm_streaming_callback`, which registered a callback to
be called whenever a streaming wasm compilation was started, and
`wasm_streaming_feed`, which let the JS callback modify the state of the
v8 wasm compiler.
`set_wasm_streaming_callback` cannot currently be implemented as
anything other than a binding, but `wasm_streaming_feed` does not really
need to use anything specific to bindings, and could indeed be
implemented as one or more ops. This PR does that, resulting in a
simplification of the relevant code.
There are three operations on the state of the v8 wasm compiler that
`wasm_streaming_feed` allowed: feeding new bytes into the compiler,
letting it know that there are no more bytes coming from the network,
and aborting the compilation. This PR provides `op_wasm_streaming_feed`
to feed new bytes into the compiler, and `op_wasm_streaming_abort` to
abort the compilation. It doesn't provide an op to let v8 know that the
response is finished, but closing the resource with `Deno.core.close()`
will achieve that.
In the spec, a URL record has an associated "blob URL entry", which for
`blob:` URLs is populated during parsing to contain a reference to the
`Blob` object that backs that object URL. It is this blob URL entry that
the `fetch` API uses to resolve an object URL.
Therefore, since the `Request` constructor parses URL inputs, it will
have an associated blob URL entry which will be used when fetching, even
if the object URL has been revoked since the construction of the
`Request` object. (The `Request` constructor takes the URL as a string
and parses it, so the object URL must be live at the time it is called.)
This PR adds a new `blobFromObjectUrl` JS function (backed by a new
`op_blob_from_object_url` op) that, if the URL is a valid object URL,
returns a new `Blob` object whose parts are references to the same Rust
`BlobPart`s used by the original `Blob` object. It uses this function to
add a new `blobUrlEntry` field to inner requests, which will be `null`
or such a `Blob`, and then uses `Blob.prototype.stream()` as the
response's body. As a result of this, the `blob:` URL resolution from
`op_fetch` is now useless, and has been removed.
This adds support for the URLPattern API.
The API is added in --unstable only, as it has not yet shipped in any
browser. It is targeted for shipping in Chrome 95.
Spec: https://wicg.github.io/urlpattern/
Co-authored-by: crowlKats < crowlkats@toaxl.com >
This splits the previous `op_url_parse` into:
- `op_url_parse`: parses a href with an optional base
- `op_url_reparse`: reparses a href with a modifier
This is a cleaner separation of concerns and it allows us to optimize & simplify args passed. Resulting in a 25% reduction in call overhead (~5000ns/call => ~3700ns/call in url_ops bench on my M1 Air)
The streaming WASM support code inspects the Response object's
Content-Type header but if that was missing, it failed with a fairly
inscrutable "String.prototype.toLowerCase called on null or undefined"
exception. Now it raises a more legible "Invalid WebAssembly content
type" exception.
