Home/ Questions/Q 7556451
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T11:51:42+00:00

We have a REST interface that returns encrypted messages. When we receive a request

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The Accept-Encoding header is about which Content-Transfer-Encoding the 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.

    • 0