- 최신
- 최다 투표
- 가장 많은 댓글
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%
관련 콘텐츠
- AWS 공식업데이트됨 2년 전
examples of currupted input:
as you see- \0 character is currupted character
legal content: