When a paid WooCommerce download starts but stops early, the customer may already have valid access. Investigate the file-delivery path before recreating permissions or making the original file public. A successful HTTP response is not proof that the complete archive reached the customer.
Build one reproducible transfer
Use a staff-controlled purchase and a known test file. Record its size and a SHA-256 hash before uploading. Keep the download URL private because order-specific links may grant access. Do not paste them into shared analytics, public issue trackers or third-party URL checkers.
Download through the same My Account or email path used by the customer. Record elapsed time, received bytes and whether the file opens. If a small file succeeds and a larger file consistently stops around the same duration, investigate timeouts and delivery limits. If both fail immediately, start with download entitlement and access.
Identify the serving method
WooCommerce's download handling guide distinguishes PHP-mediated Force Downloads, server-assisted X-Accel-Redirect or X-Sendfile, and direct redirects. Server-assisted delivery requires host configuration. Redirecting to an openly accessible paid file is not an acceptable shortcut.
Ask the host which process actually sends the bytes. Draw the route from WooCommerce authorization through storage, proxy and CDN. A PHP timeout is only one possibility; the proxy or remote storage request can terminate a transfer too.
| Evidence |
Investigate next |
| Repeatable time cutoff |
PHP, proxy and upstream time limits |
| HTML saved as an archive |
Authentication, error response or redirect |
| Complete size but wrong hash |
Wrong revision or altered bytes |
| Fresh download works, resume fails |
Range handling through the delivery path |
Full transfer: Hash matches original. Resume: Correct range handling. Small file: Ordinary path still works. Privacy: No access URLs in logs. Explanatory checklist, not a customer test result.
Check resumed transfers carefully
The HTTP range documentation explains partial responses and Content-Range. When the serving path supports ranges, test interruption and resume using your own test purchase. A 206 response describes a partial transfer; compare the returned range with the requested interval rather than expecting the entire file size in that response.
A server can ignore a range request and return the whole resource. That is different from corrupting a partial response. Do not add a misleading Accept-Ranges header unless the actual serving implementation honors it correctly.
Preserve only redacted timing and status evidence from logs. Repeated test requests may affect a limited download allowance, so use a purpose-built test entitlement and record its counter before and after the experiment.
Accept a delivery repair, not an access bypass
After the hosting change, repeat an uninterrupted transfer and the resume test where supported. Compare the completed file hash with the original, then open the archive or document. Confirm the wrong customer and a logged-out visitor still cannot fetch the protected original directly.
Finally, test one small file so the repair does not break the common path. HandL WP can coordinate the WooCommerce and hosting investigation with the method, cutoff time, file size and redacted response evidence. Do not raise every timeout indefinitely before identifying the responsible component.
References reviewed October 10, 2026. Examples are explanatory, not customer test results.