have you tried not doing anything in the reverse proxy?

Reverse proxies are supposed to be very "transparent" so every client
request should reach the backend untouched (except for needed headers) and
reply from backend must be delivered to client untouched, let them both
server and client handle the compression-decompression.

2017-04-28 17:36 GMT+02:00 Markus Gausling <markusgausl...@googlemail.com>:

> I am not sure exactly how I can configure that, i.e. when I used the
> following:
>
> <IfModule mod_deflate.c>
>      RequestHeader set Accept-Encoding gzip
>      SetOutputFilter INFLATE
>
>      SetOutputFilter DEFLATE
> </IfModule>
>
> How would Apache know that the content when going to the backend shall be
> compressed while the content provided to the clients shall be decompressed?
>
> Forward Proxy Use Case:
>
> Client               Forward Proxy                      Backend
>   |                      |                                  |
>   |   HTTP POST          |                                  |
>   |  (
> ​Body ​
> uncompressed) |                                  |
>   |--------------------->|                                  |
>   |                      |  HTTP POST                       |
>   |                      |  Content-Encoding: gzip          |
>   |                      |  Accept-Encoding: gzip           |
>   |                      |--------------------------------->|
>   |                      |                                  |
>   |                      |  200 OK                          |
>   |                      | (Resp. body might be compressed) |
>   |                      |<---------------------------------|
>   |                      |                                  |
>   |  200 OK              |                                  |
>   | (Body uncompressed)  |                                  |
>   |<---------------------|                                  |
>   |                      |                                  |
>
>
>
> The GET requests for Forward Proxy and Reverse Proxy are similar.
> Proxy adds "Accept-Encoding: gzip" header to
> ​ each​
> client request. If
> content
> ​ ​
> from Backend comes compressed it will be decompressed and
> returned with
> ​ ​
> correct header type to client:
>
> Client               Reverse Proxy                      Backend
>   |                      |                                  |
>   |   HTTP GET           |                                  |
>   |  (
> ​Body ​
> uncompressed) |                                  |
>   |--------------------->|                                  |
>   |                      |  HTTP GET                        |
>   |                      |  Accept-Encoding: gzip           |
>   |                      |--------------------------------->|
>   |                      |                                  |
>   |                      |  200 OK                          |
>   |                      |
> ​ ​
> Content-Encoding: gzip
> ​  ​
>         |
>   |                      |<---------------------------------|
>   |                      |                                  |
>   |  200 OK              |                                  |
>   | (Body uncompressed)  |                                  |
>   |<---------------------|                                  |
>   |                      |                                  |
>
>
>
> 2017-04-28 15:57 GMT+02:00 Luca Toscano <toscano.l...@gmail.com>:
>
>> Hi Markus,
>>
>> 2017-04-26 12:21 GMT+02:00 Markus Gausling <markusgausl...@googlemail.com
>> >:
>>
>>> Hello,
>>>
>>> I am using Apache (2.4.10) as an HTTP Proxy with two virtual hosts
>>> listening
>>> on different ports:
>>> - Forward Proxy
>>> - Reverse Proxy
>>>
>>> Depending on the use case applications either use the Forward Proxy or
>>> the
>>> Reverse Proxy.
>>>
>>> Now I want to make sure that for both virtual hosts the proxy does
>>> handles
>>> content compression (using gzip). Basically there are two use cases that
>>> need to be configured:
>>> - Use Case 1 - Request compressed content and decompress received content
>>> - Use Case 2 - Compress outgoing traffic (HTTP POST)
>>>
>>> This is to ensure that applications using any of the two HTTP Proxies do
>>> not
>>> need to handle content inflation/deflation (besides other things the
>>> proxies are configured to do).
>>> The applications are basically simple libcurl programms that shall be
>>> kept as
>>> simple as possible, which is the reason of this exercise.
>>>
>>> Use Case 1 works fine when I add the "Accept-Encoding: gzip" header to
>>> each
>>> outgoing request and when I inflate received content. This is achieved
>>> by
>>> adding the following to the Virtual Host section of each proxy:
>>>
>>> <IfModule mod_deflate.c>
>>>     RequestHeader set Accept-Encoding gzip
>>>     SetOutputFilter INFLATE
>>> </IfModule>
>>>
>>> My problem is that I am not able to configure the Virtual Hosts so that
>>> each
>>> HTTP POST request from an application (with uncompressed body) gets
>>> deflated
>>> in the HTTP Proxy before being sent to the Web Server.
>>>
>>> So my questions are:
>>> - Is this supported by mod_deflate anyway?
>>> - How would I need to configure mod_deflate for this?
>>> - Do I need to handle the Forward and the Reverse Proxy separately or is
>>> the
>>>  configuration the same?
>>>
>>
>> I am probably missing something important but I'd have just used
>> SetOutputFilter DEFLATE for your use cases. My assumption is that the
>> reverse proxy can handle request compression and does not pass any
>> (compressed) requests to the backend as they are, because it shouldn't
>> assume anything about the backend (like being able to handle compression).
>> The HTTP POST outgoing traffic should be deflated with the SetOutputFilter
>> directive as every response returned by the proxy (or maybe a subset of
>> them, depending on the config).
>>
>> Luca
>>
>>
>


-- 
*Daniel Ferradal*
IT Specialist

email         dferradal at gmail.com
linkedin     es.linkedin.com/in/danielferradal

Reply via email to