Comments (12)
I don't really understand why Web Transport does that. That seems like a bug. We decided that we'd use Uint8Array generally for byte buffer representation.
from fetch.
Hmm, it makes sense to return Uint8Array but I don't see the point to accept only Uint8Array?
from fetch.
The Encoding APIs also accept (AllowShared)BufferSource via TextDecoder[Stream] and emits Uint8Array via TextEncoder[Stream], which makes sense to me. Would be nice to do some IDL crawl and see how many APIs are currently accepting Uint8Array or BufferSource.
from fetch.
Would be nice to do some IDL crawl and see how many APIs are currently accepting Uint8Array or BufferSource.
Do the pages https://dontcallmedom.github.io/webidlpedia/names/BufferSource.html and https://dontcallmedom.github.io/webidlpedia/names/Uint8Array.html from https://dontcallmedom.github.io/webidlpedia/names/ accomplish what you want?
from fetch.
Thanks Andrew! That clearly shows BufferSource is winning 🥇
from fetch.
Someone will have to figure out why we made this decision this way as there was a reason and I'd rather not flip on it based on popularity. I suspect you can find the rationale either in this repository, Streams, or the "fetch with streams" repository (not sure what the link is, but it should be linked from issues in this repository).
from fetch.
The first addition happened in #449, Anne in 2016 said allowing only Uint8Array is the goal in #441 (comment), I don't immediately see the background behind that but I assume maybe that was what implementations did?
from fetch.
No, it was aspirational. Initially we designed it such that (byte) streams would only emit Uint8Array to consumers. And later we adopted that for the other direction as well. Mainly for consistency I think, but also with some hope that would allow optimizations.
Most things in the platform that accept buffers should indeed accept BufferSource, but they're not dealing with streams.
from fetch.
Mainly for consistency I think
Emit Uint8Array, so accept only Uint8Array too, you mean? Kinda make sense but still not consistent with other APIs at this point.
but also with some hope that would allow optimizations.
Do you remember in what way it can allow optimizations? Getting bytes from typed arrays should be straightforward both in JS and C++, so I don't really follow here.
from fetch.
I don't think byte streams have to be consistent with other APIs necessarily. They're somewhat unique. Also, consistency within seems more important.
from fetch.
I mean, ReadableByteStreamController accepts ArrayBufferView instead of just Uint8Array: https://streams.spec.whatwg.org/#ref-for-rbs-controller-enqueue (Not BufferSource, hmm.)
Edit: Based on that I still think "Emit Uint8Array, receive more broad types" pattern is used across many specs and thus gives consistency.
from fetch.
Here is an inconsistency:
// One can enqueue Uint16Array with type: bytes
await new Response(new ReadableStream({
start(c) {
c.enqueue(new Uint16Array([0xD55C, 0xAE00]));
c.close();
},
type: "bytes"
})).blob()
// But this fails
await new Response(new ReadableStream({
start(c) {
c.enqueue(new Uint16Array([0xD55C, 0xAE00]));
c.close();
}
})).blob()
from fetch.
Related Issues (20)
- Define behavior for `Priority` request header HOT 3
- Clarity of Location URL Algorithm HOT 1
- CORB is blocked HOT 1
- RequestInit::priority lacks corresponding Request::priority attribute
- Referrer determination should be done on updated URLs in main fetch
- Automatic decompression should sanitize `Content-Encoding` and `Content-Length` headers from the response HOT 1
- When there is an issue with the URL parameter, fetch does not have any errors
- add a method to get a Uint8Array to Body HOT 4
- Fetch with Flask or Microdot HOT 1
- Service worker "handle fetch" seems to assume it's called in parallel HOT 2
- Redirect loop handling not discussed
- Add compression dictionary negotiation and decoding to the fetch processing model HOT 2
- Reconsider default Accept values for images
- Fetch support for explicit resource management
- Consider renaming or replacing http3only? HOT 1
- [render-blocking] The links of "render-blocking" in fetch are vague HOT 2
- Define what consequences NULL bytes (0x00) or other invalid values in header names have HOT 1
- 0x00 byte (%00) in a data: URL
- fetch does not allow caching requests with a null client HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fetch.