cancel
Showing results for 
Search instead for 
Did you mean: 
Troja
Level 14

Content-Encoding Header vs. chunked encoding

Jump to solution

Hi all,

i discussed a behavior with a customer. Can anyone give me a hint?

When a client connects to MWG the HTTP request header shows the following header.

ContentEncoding:  gzip

MWG itself removes this header completely and an additional header is added.

TransferEncoding:  chunked

My questions are:

- is this a normal behavior?

- is this behavior ducumented in any RFC?

- is it possible to configure MWG to send the ContentEncoding Header anyway?

Best,

Thorsten

0 Kudos
1 Solution

Accepted Solutions
asabban
Level 17

Re: Content-Encoding Header vs. chunked encoding

Jump to solution

Hello,

if responses from web servers are encoded MWG will decode them in order to apply filters. Because re-encoding would take a lot of resources MWG does not re-encode any traffic but sends it to the client decoded. One of the reasons to use encoding is to save bandwidth and the usual use case for a proxy is to have it in-house, so this behaviour is as designed.

I don't think that this behaviour is forbidden by RFCs. Both connections (Client <-> MWG and MWG <-> Server) are valid HTTP connections.

I have seen a couple of FMRs to keep the gzip encoding, but as far as I know at the moment this is only possible by calling an HTTP Tunnel event and do not parse the response through the rule engine, which means it will not be filtered.

Best,

Andre

0 Kudos
3 Replies
asabban
Level 17

Re: Content-Encoding Header vs. chunked encoding

Jump to solution

Hello,

if responses from web servers are encoded MWG will decode them in order to apply filters. Because re-encoding would take a lot of resources MWG does not re-encode any traffic but sends it to the client decoded. One of the reasons to use encoding is to save bandwidth and the usual use case for a proxy is to have it in-house, so this behaviour is as designed.

I don't think that this behaviour is forbidden by RFCs. Both connections (Client <-> MWG and MWG <-> Server) are valid HTTP connections.

I have seen a couple of FMRs to keep the gzip encoding, but as far as I know at the moment this is only possible by calling an HTTP Tunnel event and do not parse the response through the rule engine, which means it will not be filtered.

Best,

Andre

0 Kudos
Troja
Level 14

Re: Content-Encoding Header vs. chunked encoding

Jump to solution

Hi Andre,

this is the information i was looking for.

From my side it would be great to control this behavior with "Enable Proxy Control" .

Best,

Thorsten

0 Kudos
timode
Level 9

Re: Content-Encoding Header vs. chunked encoding

Jump to solution

Hi,

are there any plans on this? Would be great to be able to control this behaviour.

cheers

Timo

0 Kudos