| Summary: | Can not determine disconnected vs finished/completed chunked response body with ReadableStream | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Benjamin Hindman <benjamin.hindman> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Blocker | CC: | ap, beidson, cdumez, karlcow, mike, webkit-bug-importer, youennf |
| Priority: | P2 | Keywords: | BrowserCompat, InRadar |
| Version: | Safari 15 | ||
| Hardware: | Mac (Intel) | ||
| OS: | macOS 12 | ||
https://wpt.fyi/results/fetch/api/basic/error-after-response.any.html is an example with bad chunck encoding where the error mechanism is correctly implemented. I would think CFNetwork detects the issue, sends it to WebKit level which error the response body stream. I did a try with WPT server with chunk encoding and it indeed seems like we do not receive an error. I would guess CFNetwork might not always detect this error case. Repro steps:
1. Run Tools/Scripts/run-webkit-httpd
2. Add LayoutTests/imported/w3c/web-platform-tests/trickle-chunk-encoding.py file as follows
-----
import time
def main(request, response):
delay = float(request.GET.first(b"ms", 500)) / 1E3
count = int(request.GET.first(b"count", 50))
# Read request body
request.body
time.sleep(delay)
if not b"notype" in request.GET:
response.headers.set(b"Content-type", b"text/plain")
response.headers.set(b"Transfer-Encoding", b"chunked")
response.write_status_headers()
time.sleep(delay)
for i in range(count):
response.writer.write_content(b"a\r\nTEST_CHUNK\r\n")
time.sleep(delay)
-----
3. Go to http://localhost:8800 and open web inspector
4. Paste the following code in the web inspector:
----
test = async (url) => {
const response = await fetch(url);
const reader = response.body.getReader();
try {
while (true) {
const { done, value } = await reader.read();
if (done) {
// Safari always goes here if the server crashes.
console.log('done');
break;
}
} catch (e) {
console.warn(e);
}
}
----
5. Run `test("trickle-chunk-encoding.py")`
6. Stop abruptly the WPT server
7. Observe whether the web inspector console shows done or an error
Chrome shows an error, Safari shows done.
It might be good to check what happens at CFNetwork level.
|
It does not appear to be possible to differentiate between a disconnected stream and a finished/completed stream. Consider: --------------------------------------------- const response = await fetch(...); const reader = response.body.getReader(); try { while (true) { const { done, value } = await reader.read(); if (done) { // Safari always goes here if the server crashes. break; } else { // ... } } } catch (e) { // Chrome and Firefox always goes here if the server crashes. console.log(e); } --------------------------------------------- If the server crashes while reading from the `ReadableStream` reader, Safari will tell us that we are done while Chrome and Firefox will correctly tell us that the connection was disconnected. Safari should only tell us that we are done if it has received '0\r\n\r\n', which it most definitely has not. Or is there some other way to differentiate this case that is cross-browser?