
今天接到一个客诉,描述:
某个 PDF 下载后无法正常打开
其提供的原始版本可以正常打开。
经查:
PDF 尺寸一致;
0x0000 0000~0x0019 0000 内容一致
0x0000 1900~0x002e 0000 内容完全不一致
所以以下两件事情你愿意相信哪件?
A 客户上传的文件本身就是错的,有一个正确的一个错误的两个版本
B 浏览器,nginx,php,aliyun oss 这几个经手文件的程序 /业务提供方,把文件内容正文弄错了。
如果是 B,谁的嫌疑最大?浏览器么?
1 oott123 2019 年 6 月 24 日 B aliyun oss |
2 no1xsyzy 2019 年 6 月 24 日 盲猜一个后面都是 0 |
5 opengps 2019 年 6 月 24 日 看大小,似乎是重新存储时候没有严格按照实际大小去标记,而是用了存储位置大小填充了。 如果是 OSS,则可能是分片上传导致的,lz 往这方面找找看 |
6 MilkShake 2019 年 6 月 24 日 1.第一个客户的 pdf 本身有问题,这个也是有一定的概率。2。看你们使用的上传方法,oss 只是存储的地方,应该跟它没关系。3.nginx 对上传文件有大小限制,可以找找相关配置文件,但是应该不会影响文件里的内容。4.还是检查一下你们的代码逻辑吧。 |
7 FrankHB 2019 年 6 月 24 日 突然想到个略相关问题:现在运营商会闲着○疼到劫持上行流量么? |
8 zarte 2019 年 6 月 24 日 换台电脑试下不就知道了么。 |
10 just1 2019 年 6 月 24 日 管他是什么,前端计算个 MD5,后端也计算一次,不对就重传 |
12 lastpass 2019 年 6 月 24 日 via Android 中间抓两次包。一次浏览器,一次接收前。看谁在捣鬼。 |
13 heixiaobai 2019 年 6 月 24 日 找客户要一下原始版本的文件,问一下客户的环境,经历还原然后上传试试 |
14 zjsxwc 2019 年 6 月 24 日 via Android 暴力二分法调试,排除下不就知道是谁的锅了 |
15 cnrting 2019 年 6 月 24 日 aliyun oss |
16 akira 2019 年 6 月 24 日 你们尝试过 上传原始版本 么.. 至少要想办法复现问题才能比较容易修正问题吧. 各环节出问题的可能性都有,但是比较常见的就是文件过大,nginx 那边没做好相关配置了 |
17 omph 2019 年 6 月 24 日 重现了吗????? |
18 Jveuy 2019 年 6 月 24 日 via iPhone 该不会是 jack 老哥吧。 |
19 phpfpm OP @aaa5838769 这个问题挺偶发的,我们 oss 用了三四年了第一次出现这样的事情被发现。 |