ERR_SPDY_PING_FAILED error with Uploader Chrome ( DropZone )

Question

I have an uploader based on http://www.dropzonejs.com/

When I upload a file bigger than 3 MB ( 13 MB ) with Chrome, I receive ERR_SPDY_PING_FAILED error in the console log.

When I upload the file, the progress bar stuck at a certain level. This is when we get this error.

I tried it with Safari, Firefox we don't have this problem.

I googled and found that others also complaining the same problem.

This is request headers from Chrome

Provisional headers are shown
Accept: application/json
Cache-Control: no-cache
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary4sLYTyIwAAXnftvv
Origin: https://www.example.com
Referer: https://www.example.com/upload/document
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
X-Requested-With: XMLHttpRequest
------WebKitFormBoundary4sLYTyIwAAXnftvv
Content-Disposition: form-data; name="_token"

GiY0lmkggP4hlyhunGRQOOBa1k1dqsr44ZgHA41e
------WebKitFormBoundary4sLYTyIwAAXnftvv
Content-Disposition: form-data; name="file[0]"; filename="sdf_brz_lin.1.jpg"
Content-Type: image/jpeg


------WebKitFormBoundary4sLYTyIwAAXnftvv--

In this stackoverflow post, they proposed some solutions but I couldn't implement their solutions since they are based on other scripts.

request stalled for a long time occasionally in chrome

They proposed something like

$(document).ready(function() {
    $.keepalive =     
            setInterval(function() {
               $.ajax({
                  url: '/ping.html',
                  cache: false
               });         
            }, 60000);    
});

But I don't know how I will integrate this solution to my dropzone.

I don't want to say visitors if they use chrome, you cannot upload bigger files than X MB...

Kitchenette

Answer 1

I just traced one of these. It was caused by the upload target server's HTTP2 receive window setting being too large.

With enough proxies or other things in between the client and the server, the total TCP bufferage between the two endpoints was enough to swallow the end of the upload, yet not finish delivering it until significantly later.

The browser got bored waiting for completion. When the browser gets bored, it gets paranoid, and sends a HTTP2 PING to check if the connection is still alive. (Seeing as it's getting constant HTTP2 updates on how much the receiver has actually received so far, this seems unnecessary/a bug!)

The PING goes into the same multiplexed HTTP2 TCP connection as the traffic, and gets trapped there until the PING timeout is reached. The client loses faith and kills the connection, which is unhelpful, as it's actually still alive!

By reducing the HTTP2 receive window to a sensible value, the browser won't be allowed to send enough to cause a huge traffic jam.

If you can't get the server to do that, you can use the browser F12 network diagnostic tools to throttle the upload rate to a value that matches at most the smallest bandwidth bottleneck in the chain - the traffic jams cannot form, meaning PINGs cannot timeout.

You can likely call this a manifestation of the Bufferbloat problem.

Ostap

Answer 2

Hi this is a network issue as far as I'm concerned. Since if we connect the System to IPV6 network this issue happens. On ipV4, uploads works like charm.

Cidevant