为什么同一个文件有些服务器 return 不同 content-length？
Why some servers return different content-length for the same file?
我正在开发一个 Android DownloadManager 应用程序，我遇到了这样一种情况，即某些服务器（例如 Linkedin 服务器）针对相同的响应 header 发送不同的 content-length文件。例如，下面的 link 表示 Linkedin 上的一张图片：
https://media-exp1.licdn.com/dms/image/C5622AQH-gfIVQhjzUw/feedshare-shrink_2048_1536/0/1615695432381?e=1619049600&v=beta&t=-zbenzxOleARjnxVRMlsX-_6gmlvhzU0-2M-peUHLyI
当我发送 HEAD 请求（使用 POSTMAN）获取图像信息时，有时 Content-Length 是 77241，有时是 79191。我知道图像的实际大小是 79191 字节，但我不知道为什么它在大多数情况下发送 77241。
如有任何帮助，我们将不胜感激。
我不知道这是怎么发生的，但通过使用另一种策略获取文件的大小，问题已经解决（至少到现在为止）。
我以前做的是向服务器发送 HEAD 请求并读取它的 Content-Length。但正如我提到的，有时发送的 content-length 是错误的。所以我发送了一个 GET 请求，其中 Range header 等于 0-255 我检查了响应中是否存在 Content-Range header headers 与否。如果存在，我会从中提取文件大小，因为它的值格式如下：bytes 0-255/79191 和 79191 是正确的文件大小。
如果 Content-Range 不存在，我发送一个没有 Range header 的 HEAD 请求，并从 Content-Length header 获取文件大小。我认为以这种方式文件大小是可靠的。我错了吗？
我正在开发一个 Android DownloadManager 应用程序，我遇到了这样一种情况，即某些服务器（例如 Linkedin 服务器）针对相同的响应 header 发送不同的 content-length文件。例如，下面的 link 表示 Linkedin 上的一张图片：
https://media-exp1.licdn.com/dms/image/C5622AQH-gfIVQhjzUw/feedshare-shrink_2048_1536/0/1615695432381?e=1619049600&v=beta&t=-zbenzxOleARjnxVRMlsX-_6gmlvhzU0-2M-peUHLyI
当我发送 HEAD 请求（使用 POSTMAN）获取图像信息时，有时 Content-Length 是 77241，有时是 79191。我知道图像的实际大小是 79191 字节，但我不知道为什么它在大多数情况下发送 77241。
如有任何帮助，我们将不胜感激。
我不知道这是怎么发生的，但通过使用另一种策略获取文件的大小，问题已经解决（至少到现在为止）。
我以前做的是向服务器发送 HEAD 请求并读取它的 Content-Length。但正如我提到的，有时发送的 content-length 是错误的。所以我发送了一个 GET 请求，其中 Range header 等于 0-255 我检查了响应中是否存在 Content-Range header headers 与否。如果存在，我会从中提取文件大小，因为它的值格式如下：bytes 0-255/79191 和 79191 是正确的文件大小。
如果 Content-Range 不存在，我发送一个没有 Range header 的 HEAD 请求，并从 Content-Length header 获取文件大小。我认为以这种方式文件大小是可靠的。我错了吗？