在PUT请求中传输编码gzip

Question

我正在使用REST API创作服务，使人们能够上传某些类型的文档。我希望在上传过程中压缩这些文档（出于带宽原因），但它们不会以压缩方式存储在我的服务中。我有一个客户端SDK，但客户可以根据我发布的REST文档自由实现自己的库来上传内容。我已经查看了最高答案here，并确定传输编码可能是更合适的机制。

但是，在PUT请求期间启用传输编码的文档/示例非常少。 RFC似乎花费大量文本围绕来自服务器的传输编码响应，但不是相反。

如果我选择沿着这条路走下去，我想澄清一些事情：

1. 根据RFC 7230，gzip的传输编码必须始终使用chunked的第二个编码。就我而言，并不是严格要求的，因为发件人确实知道正在发送的文件的全长。但是根据标准，我必须在服务器上实现分块编码。 RFC指示如果指定了传输编码，则不应指定内容长度，并且应使用分块编码框架来描述消息的结尾。这准确吗？我问这个，因为我的服务需要支持分块编码，我想尽可能避免编写。
2. 对于传输编码响应，服务器有一种机制（TE：Transfer-Encoding :)与客户端协商它支持的算法。但是客户端与服务器交互没有这种机制。如果出于某种原因，将来我想在我的服务上停止支持gzip transfer-encoding，除了向客户端返回501（未实现）错误之外还有其他选择吗？这将是各种各样的改变，并可能使一些客户完全停止工作。理想情况下，我希望客户端查询服务器是否支持特定编码，然后才开始使用该编码发送消息。有什么有趣的方法可以做到吗？

Answer 1

gzip作为传输编码并未广泛实施（如果有的话），也不存在于HTTP / 2中。

您认为gzip是内容编码吗？有关详细信息，请参阅https://greenbytes.de/tech/webdav/rfc7694.html。