In the web specification, an ArrayBufferView is explicitly a TypedArray/DataView that views an ArrayBuffer. Unless marked as AllowShared, an ArrayBufferView cannot be backed by a SharedArrayBuffer, nor can a BufferSource be a SharedArrayBuffer itself (whatwg/webidl#353), and compliant implementations will consider these invalid. This impacts many APIs that interact with byte sources.
The compliance with this in Node.js's various web API implementations is really hit-and-miss, and there's no indication that any divergence is deliberate. (WPT does not cover these cases.)
| API |
component |
compliance |
|---|
| Fetch |
BodyInit |
Partial.
✅ SharedArrayBuffers are rejected as invalid sources.
❌ Views on SharedArrayBuffers are accepted, and result in the source being copied into a new SharedArrayBuffer internally. |
| WebSockets |
WebSocket#send() |
Partial.
✅ The data parameter rejects SharedArrayBuffers.
❌ Views on SharedArrayBuffers are accepted. |
| File |
BlobPart |
❌ Both SharedArrayBuffers and views on SharedArrayBuffers are accepted as valid sources. |
| Streams |
ReadableStreamBYOBReader#read() |
❌ The view argument accepts views on SharedArrayBuffers.
This will result in delayed errors, as the underlying SharedArrayBuffer cannot be transferred. |
ReadableByteStreamController#enqueue() |
❌ The chunk argument accepts views on SharedArrayBuffers. |
| Compression Streams |
CompressionStream and DecompressionStream chunk type |
❌ Does not accept ArrayBuffers at all, as the webstream wraps an underlying Duplex. (#43433)
❌ Accepts views over SharedArrayBuffers. |
| Encoding |
TextDecoder#decode() |
✅ The API specifies AllowSharedBufferSource. |
| Web Cryptography |
data parameters |
✅ Validates input to be an ArrayBuffer or non-shared ArrayBufferView. |
internal/crypto/webidl already defines compatible validators for non-shared BufferSource and ArrayBufferView types. These should probably be moved into the internal/webidl namespace and used more widely across the various web API implementations.
cc: @nodejs/web-standards
In the web specification, an ArrayBufferView is explicitly a TypedArray/DataView that views an ArrayBuffer. Unless marked as AllowShared, an ArrayBufferView cannot be backed by a SharedArrayBuffer, nor can a BufferSource be a SharedArrayBuffer itself (whatwg/webidl#353), and compliant implementations will consider these invalid. This impacts many APIs that interact with byte sources.
The compliance with this in Node.js's various web API implementations is really hit-and-miss, and there's no indication that any divergence is deliberate. (WPT does not cover these cases.)
BodyInit✅ SharedArrayBuffers are rejected as invalid sources.
❌ Views on SharedArrayBuffers are accepted, and result in the source being copied into a new SharedArrayBuffer internally.
WebSocket#send()✅ The
dataparameter rejects SharedArrayBuffers.❌ Views on SharedArrayBuffers are accepted.
BlobPartReadableStreamBYOBReader#read()viewargument accepts views on SharedArrayBuffers.This will result in delayed errors, as the underlying SharedArrayBuffer cannot be transferred.
ReadableByteStreamController#enqueue()chunkargument accepts views on SharedArrayBuffers.CompressionStreamandDecompressionStreamchunk type❌ Accepts views over SharedArrayBuffers.
TextDecoder#decode()dataparametersinternal/crypto/webidlalready defines compatible validators for non-shared BufferSource and ArrayBufferView types. These should probably be moved into theinternal/webidlnamespace and used more widely across the various web API implementations.cc: @nodejs/web-standards