website statistics
Error 502 “The data is invalid” while browsing Internet through TMG 2010 RC - Yuri Diogenes's Blog - Site Home - TechNet Blogs

Yuri Diogenes's Blog

Thoughts from a Senior Knowledge Engineer @ Microsoft Data Center, Devices & Enterprise Client – CSI (Solutions Group)

Error 502 “The data is invalid” while browsing Internet through TMG 2010 RC

Error 502 “The data is invalid” while browsing Internet through TMG 2010 RC

  • Comments 8
  • Likes

1. Introduction

 

This post is about a specific condition that can triggers the error 502 while browsing some web sites through TMG 2010 RC. The error message that the end users receives is similar to the one shown below:

 

 

 

The TMG Logging will not say much beyond as shown below:

 

This scenario was interesting because it was working sometimes but it didn’t work most of the time. Looking closely to the data I notice that when it works is because it hits one specific server in the destination web farm and when doesn’t work it hits another web server.

2. Understanding the Behavior

 

Using network monitor was possible to better understand why this happen:

 

1) The HTTP Header when it works:

- Http: Response, HTTP/1.1, Status Code = 200, URL: /

    ProtocolVersion: HTTP/1.1

    StatusCode: 200, Ok

    Reason: OK

    Date:  Tue, 13 Oct 2009 15:57:06 GMT

    Server:  WEBSRV

    Expires:  Mon, 26 Jul 1997 05:00:00 GMT

    Cache-Control:  private, no-store, no-cache, must-revalidate, post-check=0, pre-check=0

    Pragma:  no-cache

    P3P:  CP="SRV"

    Set-Cookie:  reg_fb_gate=http%3A%2F%2Fwww.fabrikam.com%2F; path=/; domain=.fabrikam.com

    Set-Cookie:  reg_fb_ref=http%3A%2F%2Fwww.fabrikam.com%2F; path=/; domain=.fabrikam.com

    Set-Cookie:  test_cookie=1; path=/; domain=.fabrikam.com

    Set-Cookie:  lsd=zCI0G; path=/; domain=.fabrikam.com

    Connection:  close

    TransferEncoding:  chunked

  + ContentType:  text/html; charset=utf-8

    ContentEncoding:  gzip

    HeaderEnd: CRLF

  + chunkSize: 10

  - ChunkPayload: HttpContentType =  text/html; charset=utf-8

     HtmlElement: ­

    FooterEnd: CRLF

  + chunkSize: 8192

  - ChunkPayload: HttpContentType =  text/html; charset=utf-8

 

We can see that the HTTP response says that the following content will be chucked and after that response, destination server sends the other HTTP chucks:

 

WEBSRV      TMG  HTTP  HTTP:HTTP Payload, URL: /

WEBSRV      TMG  HTTP  HTTP:HTTP Payload, URL: /

WEBSRV      TMG  HTTP  HTTP:HTTP Payload, URL: /

 

2) HTTP Header when doesn’t work

 

- Http: Response, HTTP/1.1, Status Code = 200, URL: /

    ProtocolVersion: HTTP/1.1

    StatusCode: 200, Ok

    Reason: OK

    Cache-Control:  private, no-store, no-cache, must-revalidate, post-check=0, pre-check=0

    Expires:  Mon, 26 Jul 1997 05:00:00 GMT

    P3P:  CP="WEBSRV2"

    Pragma:  no-cache

    Set-Cookie:  lsd=PQ6kd; path=/; domain=.fabrikam.com

    Set-Cookie:  reg_fb_gate=http%3A%2F%2Fwww.fabrikam.com%2F; path=/; domain=.fabrikam.com

    Set-Cookie:  reg_fb_ref=http%3A%2F%2Fwww.fabrikam.com%2F; path=/; domain=.fabrikam.com

    Set-Cookie:  test_cookie=1; path=/; domain=.fabrikam.com

    ContentEncoding:  gzip

  + ContentType:  text/html; charset=utf-8

    X-Cnection:  close

    Date:  Tue, 13 Oct 2009 15:38:13 GMT

    ContentLength:  9970

    HeaderEnd: CRLF

  + payload: HttpContentType =  text/html; charset=utf-8

 

Notice that the failing server don’t say that the content is chucked, however it is still sending more chucks after that:

 

WEBSRV2      TMG  HTTP  HTTP:HTTP Payload, URL: /

WEBSRV2      TMG  HTTP  HTTP:HTTP Payload, URL: /

WEBSRV2      TMG  HTTP  HTTP:HTTP Payload, URL: /

 

Since Chunked Transfer Encoding is a mechanism that allows HTTP messages to be split in several parts the first server is answering correctly, while the second server it is not. According to RFC if a server is using chunked encoding it must set the Transfer-Encoding header to "chunked". In order to compress the content we need to accumulate all the chucks and then compress. When it works, TMG knows that all that content is part of the same HTTP request since it says in the HTTP Response Header; therefore it waits for the entire content, compress and send it back to the client. On the failing server we receive the first answer that doesn’t say that the content is chucked and right after that we receive other chucks, since HTTP Compression is enabled it fails to reassemble all the content since it doesn’t know that they belong to the same content.

 

3. What can I do to fix it?

 

The best and most correct thing to do is to contact the administrator for the destination web server and report the problem; they should fix the issue since TMG is acting correctly. However if you want a workaround, that will be disabling the HTTP compression filter.

Comments
  • Do you have any recommendations on how to fix this on the receiving side?  I recently had a similar problem, and the response back was "we can access the website just fine, so it's your proxy server that's the problem".   If there were some basic troublshooting steps I could send the website, it would help greatly.  Secondly, is there a better approach than just disabling the compression filter for all sites?  I looked and was unable to find a way to disable it only for select sites.

  • Hello Michael,

    As I said on the blog, the core issue is on the destination and on the client side the only workaround is to perform the steps that I described in this post. Unfortunetly you will need to disable to all sites.

  • Disabling compression worked for me, not ideal though.

  • Correct Judd, this is not the ideal scenario, but it is also not a TMG issue :) ... just a workaround until the destination web server fix their issue ;)

  • I followed your work around but now my users have started getting "The request is not supported. (50) errors" on some sites. The solution to this appears to be enable the compressioni filter! Again, I think the problem is the source webserver, but i'm talking about big sites here and its unlikely they will change their ways.

  • Thanks for your comments Chris. Most of the time that I had to deal with this error the issue was on the source web server. However, if you feel like there are more troubleshooting to be done on the TMG side and you need further assistance it might be a good idea to open an incident with Microsoft CSS.

    Thanks

  • I would recommend posting the text error message and as well as the image of the error.  While Googling, this blog doesn't come up since the error code is not crawled because of the image.

  • I solved the problem making an exception for the web page IP in HTTP Compression in Request Compression Data tab. I hope this could help you guys

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment