3 Replies Latest reply: Oct 31, 2013 2:30 AM by timode RSS

    Content-Encoding Header vs. chunked encoding


      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?




        • 1. Re: Content-Encoding Header vs. chunked encoding



          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.




          • 2. Re: Content-Encoding Header vs. chunked encoding

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




            • 3. Re: Content-Encoding Header vs. chunked encoding



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