Large media file download starts ok but then fails

[jjazzboss]

Hi,

I built a Netlify site www.jjazzlab.com for my (free) software application using the free plan. I use GitHub and the installation packages (~60MB files) are stored using Netlify large media. Usually it works great.

But right now when I try to download the files (for example https://www.jjazzlab.com/pkg/JJazzLab-1.0.2-Linux.zip) it randomly fails in the middle of the download. I tried on a Linux and Win10 computer (but same internet provider). I know it already happened in the past, but then it worked again.

Is it because of the free plan ? Is it because of my internet provider ? (but internet connection seems to be fine) What could I check to see what happens ?

Thanks for your help.

[perry]

hmm, i just tried to download that file you mentioned and it worked without problems.

without seeing more information from a failed download it is going to be hard to say what is going on.

can you provide a x-nf-request-id header next time a download goes wrong?

[Common Issue] Netlify Support asked for the 'x-nf-request-id' header? Why are they asking for it and how do I find it?

What is the x-nf-request-id header? Web servers and web browser communicate using a protocal HTTP - Hypertext Transfer Protocol. Both web browsers and web servers use something called headers as part of this protocol. The headers that web browsers send are called “request headers” because the browser in making an “HTTP request”. The web servers headers are called “response headers” because web servers send an “HTTP response”. Netlify creates a unique HTTP response header for each request it r…

thanks.

[luke]

@jjazzboss, if you see this again the x-nf-request-id header from the response would be the best thing to assist our troubleshooting:

[Common Issue] Netlify Support asked for the 'x-nf-request-id' header? Why are they asking for it and how do I find it?

What is the x-nf-request-id header? Web servers and web browser communicate using a protocal HTTP - Hypertext Transfer Protocol. Both web browsers and web servers use something called headers as part of this protocol. The headers that web browsers send are called “request headers” because the browser in making an “HTTP request”. The web servers headers are called “response headers” because web servers send an “HTTP response”. Netlify creates a unique HTTP response header for each request it r…

[jjazzboss]

OK I’ll do that when problem occurs again.

[jjazzboss]

Hi,

It happened again: downloading a large media file (~40MB) fails at around 16MB. I notice that, like the last time, problem happens right after I updated the large media files using git lfs (without any error, and Netlify deployed the new website as expected).

Below is the response x-nf-request-id.
5719ef3d-0169-48ae-951f-549e6766d0fa-14350402

Some additional info from the Firefox webconsole:
URL :https://www.jjazzlab.com/pkg/JJazzLab64-1.0.3-Win-Setup.exe
Method :GET
Remote address :[2a03:b0c0:3:d0::d24:5001]:443
Code d’état :200
Version :HTTP/2.0
Policy :no-referrer-when-downgrade

[fool]

Hmm. We’d expect the download to cut off at some point if it is coming slowly - maybe 28 seconds after you start if so, or at least in 90 seconds.

But in this case, looking up your specific x-nf-reuest-id, I see that we sent all 41735376 bytes with a 200 status in far less time (~12s). When I try downloading from your production URL, I get exactly that - a 41735376 exe that seems to be well formatted (I didn’t run it, but it didn’t seem corrupt).

[jjazzboss]

You mean your server sent all the data very quickly and completly ? So the problem was somewhere in between your server and my ISP ? I noticed yesterday my download speed was relatively low (90KB/sec, usually it’s more about 200-300KB/s) and it’s sure I did not receive the 40MB because in the Firefox web console the number of bytes received was written, and I could see the temporary download file xxxxx.part which was also ~16MB.

I just tried again now (24hrs later, I changed nothing on the website), and it worked OK. I noticed that today, the Firefox download window indicates the expected file size. Yesterday it did not, when it started downloading it said “unknown file size” so I did not display the download progress bar.

Is there anything I should try ?

[luke]

@jjazzboss, not to contradict a colleague but I did find different information when I checked that x-nf-request-id .

My records indicate that we did only send 16548504 bytes of data and it took 78732 ms (78.732 seconds) to send the data.

The data was sent from the CDN node near Frankfurt (which is probably the closest CDN node to you geographically).

Finally, the “result” of this HTTP request is “ERR_CLIENT_ABORT”. This means it appears to our server that the connection was ended by the system making the HTTP request.

I don’t see any errors or issue serving files from this CDN node when this occurred. From what we can see, the download was cancelled by the person/system downloading the file.

As to why it was downloading slowly, there again wasn’t any issue serving content at that time so this appears to be a bandwidth issue for the system performing the download.

The bytes downloaded were 16548504 in 78.732 seconds which is about 210188 bytes/second (~210 KBs/second). For the full file download at this rate it would take about 198.6 seconds to download this file.

To summarize, the data we have indicates that the download was slow because of the bandwidth available for the system performing the download.

If there are other questions about this, please let us know.

[jjazzboss]

Thank you Luke.

Well, obviously I did not abort myself the download so it must be Firefox. But besides the Firefox error message “Download failed” I did not find additional details. I’ll search the Firefox docs for similar issues. What is strange is that when it happened I tried downloading large files from other websites and it worked fine.

[fool]

that ERR_CLIENT_ABORT status is unlikely to be “firefox terminating the download for some reason” (unless you navigate away from the in-progress streaming download or close your browser, in which case, yes, that was intended, but more likely to be “something went wrong in transmission”. I wouldn’t spend too much time looking for more causes there, though that download speed sounds like maybe your connection is quite slow in general, which would lead to the longer download times and problems with them that I mentioned before Luke caught my mistake.