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.