Re: [whatwg/fetch] What's the difference/intended usage of the response* algorithms in fetch? (#1306)

Yeah, I need to write a guide. And per usual my problem is that I also still want to improve things.

What you want to do depends on your use case. If you want to read the body stream yourself you can use processResponse and you probably need to use processResponseDone for resource timing purposes. The latter we might be able to make optional once we have more experience with how that ends up being used by all the various callers of fetch. cc @noamr 

If your API doesn't expose intermediate signals and you just want a byte sequence to pass to a parser of sorts, you can use processResponseEndOfBody (XHR does this in a slightly weird way for its synchronous bits, but it's perfectly fine to use it in a non-weird way elsewhere). You will get a response and null, a byte sequence, or failure out of that. processResponseDone is the same as above.

Notably processResponseDone does not consume the body stream. The idea is also that it's called after trailers are received, if we ever add trailers back, but perhaps at that point we change things around a bit if we also got more experience with exposing timing information. (E.g., have a dedicated callback for trailers as there's talk about also being able to send them in the middle of responses and such.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1306#issuecomment-924690246