3 ms·

It's quite depressing that we can't have both compression and encryption at the same time - text is very compressible - particularly HTML markup...

• cesarb 11y ago
  Theoretically, you can, as long as any secrets within the response body are represented as a "literal" (that is, uncompressed) within the compressed stream. In practice, there isn't a way I know of to mark the relevant parts of the response body so that the compression, which is usually done as a separate post-processing step, will know to avoid compressing these parts of the stream. And it would be very fragile; forgetting to mark a secret as "do not compress this" would work perfectly fine but reintroduce the vulnerability.
  • derefr 11y ago
    Simply enough in HTTP2: lift out the relevant parts of the response body—turn them into separate resources and refer to them in the original object by their URL. When the client then requests those dependent objects, deliver them uncompressed. (And server-hint/push the dependent objects if you can, of course.)
• tootie 11y ago
  You can with HTTP/2.
• joeyespo 11y ago
  Could the order be reversed, encrypting first then compressing second? So only compress when sending over the wire?
  • Wilya 11y ago
    You could, but you wouldn't compress much. Encrypted data is supposed to look random, and as a consequence, it tends to compress very poorly.
    • joeyespo 11y ago
      Interesting. I was afraid that'd be the answer. Thanks for the reply.