17 March 2011

TMG - Error Code: 502 Proxy Error. The data is invalid. (13) for some sites

I had the hardest time trying to get one particular site to work from behind a TMG 2010 proxy.  The users would get.

Error Code: 502 Proxy Error. The data is invalid. (13)
IP Address: 84.233.1
Date: 17/03/2011 02:34:51 PM [GMT]
Source: web filter

This correlated with the following log event on the TMG server.

Failed Connection Attempt
Log type: Web Proxy (Forward)
Status: 13 The data is invalid.
Source: Internal ( Destination: External (84.233147:80)
Request: GET http://lc.com/PORTAL/TOPLEVEL.php
Filter information: Req ID: 0fdbab91; Compression: client=No, server=Yes, compress rate=0% decompress rate=0% 
Protocol: http 
User: anonymous

The big problem I had is that this site "worked just fine" from a direct Internet connection.

I used HTTP watch to trace the connection to the site. While goign through the STREAM view I noticed the following:
  • The page was hosted on a Red Hat Apache server.  (Just because it is at the top of the header)
  • Content Encoding was GZIP
The GZIP thing got me because only the one single page was being compressed.

When scrolling further down the stream data I saw something strange - after the gzip data segment (green) there was "clear text" again. (Amber)  I had not seen this before.

This did not look right, maybe that is what TMG was on about.  I check that the server would send me an uncompressed version of the page with some TamperData request header manipulation, and thankfully it did.

Then I moved onto the TMG to exclude the site form requesting compressed data.

  • Create a computer or computer set object.
  • Open the HTTP compression setting
  • Add the computer object to the exceptions

That finally fixed the problem loading that page.

GZIP implemented correctly is a fantastic thing - Do it badly and it cause cause issues, That is why I prefer to do all my compression on a reverse proxy TMG.

Just goes to show you TMG was correct in dropping non standard or compliant data.  Browsers were far more forgiving, this is good for compatibility but bad for standard enforcement.  So if you are getting this or a similar issue requesting data from a site, look at the site closely and see if you can spot something.


Rod said...

Had exactly the same symptoms and this article helped me sort it out. Thanks very much!

Daywalker said...

How do I do it for firewall policy?

Anonymous said...

thanx so much for your post. had the same problem and could not sort it out.
I dont know if its relevant or not but try to combine this solution with the attempt to avoid using multiple listeners with enabled authentication for the same port (ie. 443). good luck !

Anonymous said...

Thank you from Azerbaijan!

Post a Comment