Use internalResponse at end of fetch handover #1645
Conversation
There was a problem hiding this comment.
This looks mostly okay, except for some editorial work. Also, we should update the warning (as per #1512 (comment)) to indicate you might get bytes back from an opaque response and thus you have to tread carefully when not using CORS.
Regarding the comment, I want to see where we're going with #1614 before I create a merge conflict in the how-to-fetch section... WDYT? |
|
Fair, I've taken a pass at that PR and will try to do a pass at least daily until it's done. |
|
It has landed. This should now be safe to rebase and then you can add the relevant text. |
Thanks! On it |
This ensures that callers of `processResponseEndOfBody` and `processResponseConsumeBody` would receive the correct body and response without additional steps. Closes whatwg#1512
Done, please take a look if this warning is what you had in mind. |
Upon reviewing #1645 again it struck me that the first argument to processResponseConsumeBody should not be the internal response. The caller would still have all the same capabilities when it's not and it's safer if it's not.
Upon reviewing #1645 again it struck me that the first argument to processResponseConsumeBody should not be the internal response. The caller would still have all the same capabilities when it's not and it's safer if it's not.
This ensures that callers of
processResponseEndOfBodyandprocessResponseConsumeBodywould receive the correct body and response without additional steps.Closes #1512
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff