-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uploading: allow blobs, or just BufferSource? #53
Comments
At that point you might as well allow https://fetch.spec.whatwg.org/#bodyinit. |
IMO the ReadableStream chunks should be required to be BufferSource since this what Response.body provides from fetch(). We shouldn't force consumers of Response.body to have check the type on every chunk. |
If we're not doing any conversion, I tend to agree. But that would argue for only |
Uint8Array or ArrayBuffer would work for me. But yea, whatever we decided fetch() returns. I guess the trick is... we can't really enforce this. If someone provides a ReadableStream as a body we can't validate that it produces Uint8Array for every chunk. This is why I thought maybe it would be nice to be able to set a ReadableStream.chunkType that enforces that every chunk enqueued is of the right type. This could be optional for streams in general, but required for Response. |
Sure we can. Every chunk we read from the stream, we have a choice as to what we do with it. Do we error? Do we convert? Etc.
This seems like it would require inventing a way of enforcing types in JavaScript, which is a whole research project :P. |
Who is "we"? If the Response is passed to a DOM API, then sure we can codify how conversions happen. If content script both creates the Response and consumes it, though, we can't really do anything unless we are going to proxy the stream internally. |
Agreed. I thought we were talking about uploading here. |
Ok, I guess that addresses the enforcement question I had. Sorry for my confusion. I still think we should require Uint8Array or BufferSource for consistency. I think Uint8Array would be most correct, but it seems a bit punitive to force people to convert from other ArrayBufferView types. |
If we are doing any kind of conversion, I don't see why we would constrain ourselves to just |
+1 for not allowing blobs, at least for a while. I'm not sure if it is strongly wanted, and we can loose the restriction later if necessary. |
OK, sounds good. Let's maybe just stick with Uint8Array in the initial upload draft? |
Yes, let's stick with the same as what we output then. |
Let's close this. We seem to have decided on Uint8Array only for uploads, at least for now. |
Would a ReadableStream of blobs be acceptable as a body? Or would it have to be one of easily-accessible data? I don't see any reason in principle to disallow blobs.
The text was updated successfully, but these errors were encountered: