- Newest
- Most votes
- Most comments
Just throwing it out there as an idea, could this be related to cloudfront compression? Gzip or BR?
Sometimes cloudfront will compress dynamic objects some times it will not.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html
Agree I see that too.
\0 is ASCI NUL in hex
The ASCII NUL character is used to denote the end of the string in C or C++
as you see example above - there is 3 part in content: part of correct content, part of corrupted content and finally correct content. Looks like internal error of some Cloudfront's edges.
thank you for comment. Do you know can I disable it?
Hi, I don't know why you're receiving corrupted files intermittently but does the problem exist if the user downloads a file, finds the file is correct and then downloads the file again straight away, i.e. does the problem exist consistently for a period of time?
A workaround that can be good practice anyway is to upload an object containing a hash of the file alongside the actual file object. Download both the file object and hash object in your client and then compare the original hash to a hash of the object you downloaded. If they differ then try to download the file again.
redownload doesnt work. Only after few days
Few ideas-
- You can use HTTPS if you might think someone in the middle is meddling with the traffic (local daemons on the client, proxies, ISP, etc.)
- Is there a chance you are using custom error page which masks an error?
- You can use CloudFront logs to make sure the size of the response makes sense, and that the client didn't disconnected before the entire file downloaded.
I use https, no download error, im sure 100%
Relevant content
- asked a year ago
- asked 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
examples of currupted input:
as you see- \0 character is currupted character
legal content: