解决Tusd项目在Cloud Run上使用HTTP2时PATCH请求404问题

在使用Tusd项目实现大文件分片上传功能时，开发者可能会遇到一个典型问题：当服务部署在Cloud Run环境并启用HTTP2协议后，初始PATCH请求会返回404错误。本文将深入分析问题原因并提供解决方案。

问题现象

当开发者将基于Tusd的上传服务部署到Cloud Run环境，并启用HTTP2协议后，客户端（如Uppy.js或tus-js-client）发起上传请求时，第一个PATCH请求会失败并返回404状态码。通过日志分析发现，服务端记录的ID字段异常地包含了路径前缀（如"v2/files/79720155bd3c1f6e3dd9c58d7ea2b6df"），而非预期的纯文件ID。

根本原因

这个问题源于路径前缀处理不当。Tusd的处理器本身不会自动剥离路径前缀，当请求到达处理器时，如果路径中包含配置的基础路径前缀（BasePath），处理器会尝试将整个路径作为ID来处理，导致无法找到对应的上传记录。

解决方案

正确的处理方式是在请求到达Tusd处理器前，使用Go标准库的http.StripPrefix中间件移除路径前缀。具体实现如下：

// 创建子路由时使用StripPrefix处理路径
filesSubrouter := apiSubRouter.PathPrefix("/files").Subrouter()
filesSubrouter.Use(
    http.StripPrefix("/v2/files", tusHandler.Middleware),
    // 其他中间件...
)

实现要点

1. 中间件顺序：StripPrefix必须作为第一个中间件应用，确保后续处理器看到的是正确的路径
2. 路径匹配：确保StripPrefix中使用的路径与Router中定义的PathPrefix完全一致
3. 多版本支持：如果API有多个版本路径（如/v2/files和/v3/files），需要为每个版本单独配置StripPrefix

最佳实践

1. 环境测试：在开发环境同时测试HTTP1.1和HTTP2协议下的表现
2. 日志监控：在处理器前后添加日志中间件，记录实际接收到的路径
3. 单元测试：编写测试用例验证路径处理逻辑

总结

通过正确使用StripPrefix中间件，可以解决Cloud Run上HTTP2协议的兼容性问题。这个案例也提醒我们，在使用任何Web框架时，都需要清楚地理解请求路径的处理流程，特别是在有路径前缀的情况下。Tusd作为一个灵活的上传处理器，将路径处理的职责交给开发者，这既带来了灵活性，也需要开发者对HTTP路由有深入理解。

对于需要支持HTTP2协议的上传服务，除了路径处理外，还应该注意超时设置、连接管理等其他可能影响性能的因素，这些都可以在Tusd的配置中进行优化。