我正在使用REST API创建一个服务，使人们能够上传某些类型的文档 . 我希望在上传过程中压缩这些文档（出于带宽原因），但它们不会以压缩方式存储在我的服务中 . 我有一个客户端SDK，但客户可以根据我发布的REST文档自由实现自己的库来上传内容 . 我查看了最佳答案here并确定传输编码可能是更合适的机制 .
但是，在PUT请求期间启用传输编码的文档/示例非常少 . RFC似乎花费大量文本围绕来自服务器的传输编码响应，但不是相反 .
我是否应该选择沿着这条路走下去，我想澄清一些事情：
-
根据RFC 7230，gzip的传输编码必须始终使用chunked的第二个编码 . 就我而言，并不是严格要求的，因为发件人确实知道正在发送的文件的全长 . 但是根据标准，我必须在服务器上实现分块编码 . RFC指示如果指定了传输编码，则不应指定内容长度，并且应使用分块编码框架来描述消息的结尾 . 这准确吗？我问这个，因为我的服务需要支持分块编码，我想尽可能避免编写 .
-
对于传输编码响应，有一种机制（TE：Transfer-Encoding :)，服务器可以与客户端协商它支持的算法 . 但是客户端与服务器交互没有这种机制 . 如果出于某种原因，将来我想在我的服务上停止支持gzip transfer-encoding，除了向客户端返回501（未实现）错误之外还有其他选择吗？这将是各种各样的改变，并可能使一些客户完全停止工作 . 理想情况下，我希望客户端查询服务器是否支持特定编码，然后才开始使用该编码发送消息 . 有什么有趣的方法可以做到吗？
1 回答
作为传输编码的gzip没有广泛实现（如果有的话），也没有在HTTP / 2中存在 .
你认为gzip是一种内容编码吗？有关更多信息，请参见https://greenbytes.de/tech/webdav/rfc7694.html .