Comments (9)
I see two solutions I like a bit better as I don't really care for XMLHttpRequest:
- We use a more limited form of BodyInit for XMLHttpRequest
- We throw when you pass a ReadableStream and the synchronous flag is set.
Note that upload streams in general still have issues that are being sorted out in the Fetch repository.
from xhr.
So in other words, in order to transmit the request body of the fetch, we need to read from the stream, which, at least if the body is a user provided stream, will require running code on an event-loop. It that event-loop is the same that is currently blocking on the fetch call as part of a sync XHR, it appears to be an actual deadlock.
I'm confused by this paragraph, as for XHR there is no user provided stream.
from xhr.
@yutakahirano there is, send()
takes BodyInit
which consists of ReadableStream
among other things.
from xhr.
Oh sorry I missed that, thank you. Then I prefer removing that functionality from XHR. I'm not sure if which of throwing or ignoring is better.
from xhr.
Makes sense, strictly speaking even in the other BodyInit
cases those objects are extracted into a stream, and those could be said to be fully "native" streams where reading chunks would not require calling into JS.
from xhr.
How about we remove the functionality, and then implementations can still warn in their own way if needed about use of a deprecated feature?
I can open a PR...
from xhr.
On the other hand, returning an error in the stream case allows us to still use BodyInit
, versus adding a new IDL like XhrBodyInit
that would not include a stream.
But send
doesn't return an error now, so that's maybe another complication.
We could also define send like:
void send(optional (Document or Blob or BufferSource or FormData or URLSearchParams or USVString)? body = null);
The algorithm would still "work", since "Otherwise, set request body and extractedContentType to the result of extracting body" would work "as is" I think.
from xhr.
Thinking about it more I suspect implementations don't support this today and what happens is that ReadableStream gets stringified. That's acceptable to me.
I would suggest we define XMLHttpRequestBodyInit in Fetch and define BodyInit as (ReadableStream or XMLHttpRequestBodyInit). And make XMLHttpRequest use (Document or XMLHttpRequestBodyInit).
ReadableStream will stringify in IDL land and then be treated as a string in XMLHttpRequest as a result.
If you're willing to tackle this @gterzian that'd be great!
from xhr.
Ok I'll take it on, starting with the change in Fetch then.
from xhr.
Related Issues (20)
- Expose ProgressEvent to ServiceWorker HOT 14
- Handle error while reading response body in synchronous XHR HOT 1
- Reference primitive for "If one or more event listeners are registered"
- Spec requires firing at least two "progress" events; browsers do not. HOT 1
- features request:add SynXMLHttpRequest for Avoid Callback Hell Programming HOT 1
- Why do we need to remove synchronous XHR? HOT 2
- link error breaking deploys HOT 2
- Allow to send body within GET http requests HOT 1
- Aborted flag check in "handle errors" HOT 2
- interop: blob with empty content type is not converted to text/xml HOT 3
- Wrong upload progress when network interrupts HOT 3
- xmlhttprequest.responseText occasionally appears Chinese garbled characters HOT 1
- XHR: how can I read request headers? HOT 1
- Need Discussion of 'why' Behind Deprecation of sync xhr HOT 2
- Wrong algorithm + missing realm argument when creating ArrayBuffer
- Ambiguous definition/initial values of network error HOT 3
- Use HTML's parse a URL HOT 2
- FormData & submitter[formaction] HOT 6
- `FormData`: Accept `object` form in constructor HOT 1
- Clarify if `ProgressEvent.loaded` should indicate the size of compress, or uncompressed, data HOT 2
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 xhr.