在加密之前压缩数据是否违反任何网络标准来满足“接受编码：gzip、deflate”要求HTTP 请求中的标头？
我们有一个返回加密消息的 REST 接口。当我们收到带有 Accept-Encoding: gzip, deflate 标头的请求时，我们会压缩数据。目前，我们在加密数据之后压缩数据，但我们注意到在加密之前压缩数据会大大减少内容长度并提高性能。在加密之前压缩数据是否违反任何网络标准？
We have a REST interface that returns encrypted messages. When we receive a request with the Accept-Encoding: gzip, deflate header, we compress the data. Currently, we compress the data AFTER we encrypt the data, but we noticed that compressing the data BEFORE encrypting it drastically reduces the content length and would increase performance. Does compressing the data before encrypting it violate any web standards?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Accept-Encoding标头是关于客户端将接受哪种Content-Transfer-Encoding的。您没有义务仅仅因为有人说他们会接受传输中的压缩内容而进行压缩，因此，如果您在加密后根本不进行压缩，那么您并没有做错任何事情。 （如果您的加密有价值，则根本不会压缩。）您不能设置 CTE 并期望客户端在解压缩之前解密，因为 CTE 标头表示“在对 CTE 执行任何其他操作之前应用此转换”内容”。
然而，在没有 CTE 标头的加密之前进行压缩是完全合法的。就这样做，加密后不要设置 CTE 或压缩。
The
Accept-Encodingheader is about whichContent-Transfer-Encodingthe client will accept. You are not obliged to compress just because someone says they will accept compressed content in transit, so you are not doing anything wrong if you don't compress after encryption at all. (Which, if your encryption is worth anything, will not compress at all.)You can't set a C-T-E and expect the client to decrypt before they decompress, because the C-T-E header says "apply this transformation before you do anything else with the content".
However, compressing before encrypting without the C-T-E header is perfectly legal. Just do that, and don't set a C-T-E or compress after encryption.