Search code examples
restencryptioncompressiongzipweb-standards

Does compressing data before encrypting it violate any web standards to fulfill the "Accept-Encoding: gzip, deflate" header in an HTTP request?


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?


Solution

  • 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.