4 Replies Latest reply on May 31, 2012 9:33 AM by luca.scamoni

    Enable HTTP Tunnel event


      I'm trying to find out what this event is and how it can help.

      I guess it should allow to bypass the proxy feature in some way but how exctly?

      Anyone can show an example of its usage?

        • 1. Re: Enable HTTP Tunnel event



          basically the event is used to "flag" a request to be tunneled. The response coming back from the server for this flagged request(s) will not be send into the rule engine at all, but passed without touching it. This is helpful if parsing by the rule engine (e.g. enforce RFC compliance etc.) damages the response and breaks connections to a server.


          Please note that tunneled responses are not filtered.


          I think a very simple example may look like this:






          1 of 1 people found this helpful
          • 2. Re: Enable HTTP Tunnel event

            Hi Andre,

                 thanks. So what's the difference between using the event with a Continue action like your example does and using the Stop Cycle action as in Global Whitelist?

            Apart from the fact that using stop cycle MWG stops processing all following rules that can include anything from authentication to anti-malware...

            • 3. Re: Enable HTTP Tunnel event

              Hi Luca,


              the difference is that when you use "Stop Cycle" at the very first rule set in the rule engine the response has actually been given to the rule engine, which is the filtering part of MWG. So simplified you have a proxy part which takes care for getting the response from the server and the filter part which applies the rules.


              The filter part can be pretty strict. For example it failes if a server tells "I will send gzip encoded content" but sends plain text. The filter expects gzip data and may display an error, even it you have "Stop Cycle" as the first rule.


              By enabling the "HTTP Tunnel" event the proxy knows "do not give the response to the filter part of MWG". So if the data is received from the server it will directly be passed to the client, without even calling the filter (/rule engine) part of MWG. So whatever may cause the filter to not like the request can be avoided, because the filter never sees the response.


              This is really a workaround if there is something you need to get through the proxy, and you do not care for it being filtered. It may help a lot if the server sends a broken response we cannot fix or handle. In most cases I would suppose to use it as a "last resort" option, if there is no workaround with the rule engine. Also I would report such hosts/URLs to support, to have them investigated.


              Does this make sense?




              • 4. Re: Enable HTTP Tunnel event

                Yes, definitely.

                Thank you Andre.