• Resolved paddletroke

    (@paddletroke)


    I have some 400-700mb downloadable files.

    Many users are reporting to me that their downloads failed. They attempt to download many time and it very often fails around the middle.

    I checked the logs and found many of these :

    End of script output before headers: index.php, referer: https://www.astocad.com/

    (104)Connection reset by peer: AH10143: FastCGI: comm with server “/homez.254/astocat/www/index.php” aborted: read failed, referer: https://www.astocad.com/

    AH10149: FastCGI: incomplete headers (0 bytes) received from server “/homez.254/astocat/www/index.php”, referer: https://www.astocad.com/

    AH10157: FastCGI: An error happened during Fastcgi processing, fallback to CGI, referer: https://www.astocad.com/

    On which deepseek tells me :

    PHP scripts (like WooCommerce’s download handler) may exceed the max_execution_time or memory_limit, causing the PHP-FPM process to crash mid-download.

    I checked my host (ovh) limitations, and found max_execution_time =165, which I cannot change. I have asked users to confirm to me if the downloads fails at 165s and wait for confirmation.

    Do you think the max_execution_time is the reason why it’s failing? My host does not let me change this. What can I do?

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter paddletroke

    (@paddletroke)

    So it appears that this is actually described in the main page of the doc :

    Force Downloads – File downloads are forced, using PHP. To ensure files are protected from direct linking, Force Downloads can be used. However, if your files are large, or the server is underpowered, you may experience timeouts during download.

    That is exactly what is happening apparantly. So if the connection speed is such that download takes more than 3 minutes, then it fails.
    That is a serious limitation of downloadable products…

    Thread Starter paddletroke

    (@paddletroke)

    Ok so my only option is to use the ‘redirect only’ option.

    And guess what? It doesn’t work! If you select this option (and remove the .htaccess) then clicking the button does nothing.

    • Click. Nothing.
    • Right click, open in new tab : A tab appears and disappears. Nothing happens.
    • Right click, copy URL, open a new tab, paste URL. Then the download finally start…

    I even tried what is described in https://wordpress.org/support/topic/file-download-redirect-option-deprecated-what-to-do/. After this, the direct URL is associated with the button. But clicking the button still does nothing, same as above…

    • This reply was modified 1 year, 3 months ago by paddletroke.
    Thread Starter paddletroke

    (@paddletroke)

    About the redirect only option I finally found what is happening.
    The URL of my web is
    https:://www.astocad.com/
    While the URL I have put in the product pages are :
    http:://www.astocad.com/somewhere/myfile.7z

    See the difference? One is https the other http…
    After changing my files URL to https then it works.
    Somehow I think that Woocommerce should catch this and fix the URL automatically if necessary. Or add a notice about it near where we add the URL on the product page.

    Plugin Contributor Barry

    (@barryhughes-1)

    For very large files, and where a redirect is not your preferred option, it may be better to use X-Accel-Redirect/X-Sendfile option if you can (we realize that enabling this is not always possible, however), as this essentially short-circuits things and PHP’s involvement will be minimized. Some resources:

    Do you think the max_execution_time is the reason why it’s failing?

    Yes, what you’ve already noted seems quite likely. The force download method can work with very large files, but to do this reliably your host would need to lift these constraints and that is, unfortunately, out of WooCommerce’s control.

    See the difference? One is https the other http … somehow I think that Woocommerce should catch this and fix the URL automatically if necessary.

    I’m not sure that we could always reliably detect that this would be problematic. Additionally, site configurations can change and so a large number of HTTP URLs may already be in place, and then become unviable.

    However, I agree we could warn if it seems likely to cause a problem, and possibly could add a tool to correct existing entries. Would you like to propose this as a new enhancement? Some final notes:

    • There are some great options like serving large files from S3 that you might be interested in.
    • You could consider entering URLs without specifying the protocol. For example, //example.com/path/to/asset.pdf
Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘Download of large file failing often’ is closed to new replies.