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
Step 5 says "Wait for 1024 bytes of response or end-of-file, whichever comes first and let bytes be those bytes."
Step 12 says "If response's body parses as JavaScript and does not parse as JSON, then return true."
I assume the algorithm is supposed to wait for the full body, which is then parsed as JS/JSON, as opposed to using some sort of partial parser, but it's never mentioned.
So, it seems to me either:
Mentioning body bytes implicitly assumes we have waited for those bytes, and the "Wait for" in step 5 is unnecessary, or
we should mention waiting for the entire body in 12 or in a step before 12.
I'd prefer 2), to make it explicit that we need to wait for the entire body, presumably just before or in step 12.
The text was updated successfully, but these errors were encountered:
Yeah, this should do the same as whatwg/fetch#1172 implements for integrity checking. Consuming the entire body and if successful and the check is successful creating a new body with the read bytes.
Step 5 says "Wait for 1024 bytes of response or end-of-file, whichever comes first and let bytes be those bytes."
Step 12 says "If response's body parses as JavaScript and does not parse as JSON, then return true."
I assume the algorithm is supposed to wait for the full body, which is then parsed as JS/JSON, as opposed to using some sort of partial parser, but it's never mentioned.
So, it seems to me either:
I'd prefer 2), to make it explicit that we need to wait for the entire body, presumably just before or in step 12.
The text was updated successfully, but these errors were encountered: