You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Early hints (103 responses) are not the only kind of interim response the http spec allows for. It would be ideal for fetch to provide a means of receiving and processing interim responses.
Define a new FetchPromise that extends Promise<Response> and implements Symbol.asyncIterator, returning an AsyncIterable of InterimResponses. The fetch() method would return this new FetchPromise, allowing, for example:
const fetchPromise = fetch('https://...'); // note no await
for await (const interimResponse of fetchPromise) {
// process the interim response
}
const resp = await fetchPromise;
Hmm... my key concern there is that #607 (and the whole observer/events model) just feels unnecessarily overweighted for this. I could certainly be convinced otherwise, tho as FetchObserver would certainly help with other use cases.
What problem are you trying to solve?
Early hints (103 responses) are not the only kind of interim response the http spec allows for. It would be ideal for fetch to provide a means of receiving and processing interim responses.
What solutions exist today?
For fetch, none.
How would you solve it?
Define a new
InterimResponse
dictionary:Define a new
FetchPromise
that extendsPromise<Response>
and implementsSymbol.asyncIterator
, returning anAsyncIterable
ofInterimResponse
s. Thefetch()
method would return this newFetchPromise
, allowing, for example:Anything else?
Original discussion for this mechanism here: https://docs.google.com/document/d/1P4MskkFd3HHFPGDr01O3wdFXukmX9i0jAb5uh9v9x8Q/edit
The text was updated successfully, but these errors were encountered: