Gopeed项目中HTTP文件大小解析的优化实践

问题背景

在Gopeed下载项目中，开发团队发现了一个关于HTTP资源文件大小解析的问题。当用户尝试下载某些支持分片下载的HTTP资源时，系统会错误地使用Content-Length作为文件大小，而实际上应该优先从Content-Range头部获取更准确的文件大小信息。

技术分析

问题的核心在于HTTP协议的响应处理逻辑。当客户端发送一个带有Range头部的请求时，服务器可能返回两种响应：

1. 206 Partial Content：表示服务器支持并返回了部分内容
2. 200 OK：表示服务器不支持范围请求，返回完整内容

然而，在实际网络环境中，还存在第三种情况：服务器支持范围请求，但在某些条件下（如首次请求）会返回200 OK状态码，同时包含Accept-Ranges: bytes头部，表明它实际上支持分片下载。

问题复现

通过调试日志可以观察到：

1. 系统发送了一个字节范围的预探测请求
2. 服务器返回了200 OK状态码
3. 响应中包含Accept-Ranges: bytes头部
4. 同时也包含了Content-Range信息

此时系统错误地使用了Content-Length作为文件大小，而没有优先考虑Content-Range提供的信息。

解决方案

开发团队提出了以下优化方案：

1. 修改响应处理逻辑，优先从Content-Range获取文件大小信息
2. 对于非206状态码的响应，增加对Accept-Ranges头部的检查
3. 如果服务器明确支持分片下载(有Accept-Ranges: bytes头部)且状态码为200，则执行与206状态码相同的处理逻辑

实现效果

经过优化后：

1. 系统能够正确识别支持分片下载的资源
2. 准确获取文件大小信息
3. 提高了下载效率和可靠性

技术意义

这个优化不仅解决了特定场景下的文件大小解析问题，更重要的是完善了HTTP协议实现的健壮性。它展示了在实际开发中如何处理HTTP协议的边缘情况，确保下载工具能够适应各种不同的服务器实现。

这种优化对于提升用户体验至关重要，特别是在处理大文件下载时，准确的文件大小信息可以帮助用户更好地预估下载时间，也使断点续传等功能更加可靠。