Partager via

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

  • Article

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

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    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 ;)

  • Anonymous
    January 01, 2003
    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

  • Anonymous
    December 22, 2010
    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.

  • Anonymous
    January 18, 2011
    Disabling compression worked for me, not ideal though.

  • Anonymous
    February 04, 2011
    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.

  • Anonymous
    July 13, 2011
    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.

  • Anonymous
    February 27, 2014
    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