How to disable "TCP Keep-Alive" in a XMLHttpRequest

166 Views Asked by At

I am working with an embedded firmware project that has an internal HTTP(S) server. It uses an XMLHttpRequest to perform an update to the device.

The core of the AJAX code is this:

var oReq = new XMLHttpRequest();

var fileArray = [fileReader.result];
var fileBlob = new Blob(fileArray);
oReq.onreadystatechange = function() {
    if (this.readyState == XMLHttpRequest.DONE) {
       if (this.status == 200) {
             ...
        }
    }
}

oReq.open("POST", url, true);
oReq.timeout = 60000;
oReq.withCredentials = true;
oReq.send(fileBlob);

It works fine, except recently the size of the upload got a bit bigger.

When performing a large update, FireFox is sending a bunch of TCP Keep-Alive messages. Then terminating the connection after 10 of them are missed.

enter image description here

Google Chrome and Edge don't appear to do this. Not a peep from them. But FF is trying to tap on the device's shoulder every second.

The firmware is busy updating things from the upload, so it takes longer than FireFox feels like allowing. Which is about 4 seconds too long.

How can I adjust how many can be missed? Or what the spacing between them is? Or just stop the XMLHttpRequest from sending those TCP Keep-Alive's in the first place? Like Chrome and Edge do.

I've looked all over, and it seems that every possible property or setting is not allowed (or just plain doesn't work):

  • Connection: Close is a restricted header
  • Keep-Alive: xxxx is a restricted header.
  • XMLHttpRequest->timeout property doesn't do anything.

These TCP Keep-Alive's appear to be coming from deeper in the OSI stack than just an application level.

Logic prevents responding to the HTTP(S) file POST because it's an unknown if the upload is acceptable until after it's been processed (can say success or failure until we're actually done and know if it's a success or failure).

I can't believe it's in some design to limit some request/response to less than 10 seconds... And not allow the user to compensate for it. RESTful updates could take longer than that.

TIA for advice.

0

There are 0 best solutions below