Allow transformations on compressed response about django-revproxy HOT 3 OPEN

Even though I'm the one who opened this issue in first place I'm not totally convinced that we should allow transformations on compressed responses.

Actually it could be a bit silly. Imagine the scenario where we have three HTTP servers:

A - Proxied Web App
B - django-revproxy instance
C - Nginx, Varnish or any other reverse proxy app

Let's also add a fourth actor D which would be the browser performing the request.

So once D does a request it will specify (using Accept-Encoding header) if C should or should not respond with a compressed content.

C will send over the request to B (including the Accept-Encoding header) and B will send the same request to A. Currently B (which is us) removes the Accept-Encoding header.

Let's say we don't remove the encoding and that A compresses the content using gzip. In that case B would have to umcompress the content, do all it's processing and afterward compress it back before sending the response to C and then back to D. That seems good because the user got his content compressed as he was expecting.

Now what happens if instead of removing the Accept-Encoding header we set it to "identity"? Basically D would request to C that requests to B (removing the header) that requests to A that responds with a plain response to B! Is that bad? I don't know, because once C gets the response back it knows that D accepts encoded content so C will do the compression and D will get the exact same content than the scenario above.

The difference here is that the content goes from A to B and from B to C as plain contents spending a little more bandwidth and time but using less CPU as well. I'm not even sure if the time to compress is lower than the time to transfer.

I'm assuming here that this is only for HTML request/response. Since we don't apply transformations we can transfer content encoded from A to D without any problems.

Thoughts?

from django-revproxy.

In the end performance will depend on several aspects:

• whether A, B and C are together in a fast local network, and how much bandwitdh it has
• on the actual processing power of A, B and C
• on the number of nodes playing A, B, and C
• on the expeced number of clients (D)

I think you might want to add that as a configuration option, but the only way to know if it's worth letting A compress responses would be to test on an actual deployment infrastructure.

from django-revproxy.

That makes sense. Your opinion is also converging with the suggestion that @rodolphoeck gave me yesterday on IRC.

from django-revproxy.