我正在使用 REST API 创作一个服务，它使人们能够上传某些类型的文档。我希望在上传期间压缩这些文档（出于带宽原因），但它们不会以压缩方式存储在我的服务中。我确实有一个客户端 SDK，但客户可以根据我发布的 REST 文档自由实施他们自己的库来上传内容。我在这里查看了最佳答案，并确定传输编码可能是执行此操作的更合适的机制。
但是，在 PUT 请求期间启用传输编码的文档/示例非常少。RFC 似乎在从服务器传输编码响应方面花费了大量文本，但反之则不然。
如果我选择走这条路，我想澄清一些事情：
- 根据RFC 7230，gzip 的传输编码必须始终使用分块的第二种编码。就我而言，这不是严格要求的，因为发件人确实知道正在发送的文件的完整长度。但按照标准，我必须在服务器上实现分块编码。RFC 指出，如果指定了传输编码，则不应指定内容长度，并且应使用分块编码帧来描绘消息的结尾。这是准确的吗？我问这个是因为我的服务需要支持分块编码，如果可能的话，我想避免编写它。
- 对于传输编码的响应，有一种机制（TE：Transfer-Encoding:）供服务器与客户端协商其支持的算法。但是对于客户端到服务器的交互没有这样的机制。如果出于某种原因，将来我想在我的服务中停止对 gzip 传输编码的支持，除了将 501（未实现）错误返回给客户端之外，还有其他选择吗？这将是一种重大变化，可能会使一些客户端完全停止工作。理想情况下，我希望客户端查询服务器是否支持特定编码，然后才开始使用该编码发送消息。有什么有趣的方法可以做到这一点吗？