fetch issue with open connection
Categories
(Core :: DOM: Networking, defect, P2)
Tracking
()
People
(Reporter: jfv.oliveira, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged][necko-priority-next])
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
I am using the fetch method to continuously get data from a server.
Essentially if the server sends some data and closes the connection everything goes according to plan, but if it doesn't close the connection then I get the behaviour described below.
Actual results:
On the console the error "TypeError: NetworkError when attempting to fetch resource". Also looks like there is some buffering going on. After ~583 bytes of data all the data sent over the connection is flushed and it works as expected from then on. Our current solution is just to send trailing new lines on the first piece of data to fill the buffer, but this proves to be very inefficient.
Here is some context for when I first suspected this issue: https://github.com/braid-org/braidjs/issues/15#issuecomment-1069763841
Expected results:
No errors and any data gets sent without the buffering effect.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Thanks for opening this bug, jfv.oliveira!
To reproduce this, issue a fetch() request to a server like this:
fetch('/json', {headers: {subscribe: true}})
.then(res => console.log('We got data!'))
And have the server respond with the following:
HTTP/1.1 209 unknown
Range-Request-Allow-Methods: PATCH, PUT
Range-Request-Allow-Units: json
Patches: OK
subscribe: true
cache-control: no-cache, no-transform
Date: Fri, 18 Mar 2022 03:38:23 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked
11
version: "test"
14
content-length: 16
14
{"this":"stuff"}
2
And (this is key!) make sure the server leaves the response TCP connection open, rather than closing it.
We'd expect fetch() to announce "We got data!" so the client Javascript can process it, but Firefox doesn't, unless you respond with a LOT more data, or close the connection. In my tests, the response has to be at least 1944 bytes long (+/- 3 bytes), including the headers and body.
Our guess is that there's code somewhere in Firefox that's buffering network traffic and only flushes it to the fetch() client once it gets long enough. Can someone help point us to the code where this could be happening?
Updated•3 years ago
|
Comment 3•11 months ago
|
||
Discussed this internally.
Our nsHttpChunkedDecoder might not be detecting the EOF correctly.
Moving it to priority next for further investigation.
Description
•