Running ISA 2004 SP3 we get a 502 proxy error (the request is not supported) when accessing some web sites (e.g. www.voyages-sncf.com) using some ISA servers, while it works fine when using some other ISA servers (same version/sp, similar configuration). The problem apparently is caused by a GZIP compressed redirect. This redirect is received by ISA, but not returned to the client, the 502 error is returned instead and the TCP session with the web server closed.
Changing the compression settings apparently has no impact.
The ISA servers that do not work are running Surfcontrol. Not sure whether that has any impact.
Hi, I had the same problem. To solve it I turned on the compression filter (add-ins) after the sp3 installation. And my problematics sites started to work, include yours (www.voyages-sncf.com).
Hello, I faced exactly the same problem and I reactivated Compression on ISA 2004 SP3. but since, our events are fill with :
quote:
Description: ISA Server was unable to decompress a response body from http://yyyyyyyy because the response was compressed by the GB2312 method, which is not supported by ISA Server. This happens when a Web server is configured to supply responses compressed by the GB2312 method regardless of the type of compression requested.
If you want ISA Server to block such responses, configure the policy rule's HTTP policy to block the Content-Encoding header in responses. Otherwise, such responses will be forwarded without decompression to the client and can be cached.
You can cancel or reduce the frequency of the alert generated by this event in ISA Server Management.
and
quote:
Description: ISA Server was unable to decompress a response body from http://www.xxxxxxx.com because the following error occurred: 0x8007000d. This error may occur when the available memory is insufficient, the response is corrupted due to a network problem, or the server returns an illegal response.
Any idea what I have to change in my settings to make compression working ?
These event log entries are caused by servers returning content compressed by mechanisms not advertized nor supported by ISA. The problem is primarily caused by the web servers reacting in a ways they should not. As far as I know there is mo way to avoid these event log entries, other then by disabling the compression filter.
Let me make an additional note on compression. In our case the enabling of the compression filter add-in did resolve the issue with web sites returning unrequested compressed content (with the side effect of the event messages you refer to). But as soon as we start actually using compression, by setting the HTTP compression preferences, we start getting operational problems (memory errors) with many common web sites. I presume this is caused by a bug in ISA 2004. For the time being we have turned off these HTTP compression preferences, while keeping the compression filter enabled. We will test again with a next version of ISA.
Not sure this is of any help, but at least you now you are not the only one with these kinds of issues.
So.... I'm now completely lost .... may be you can help me:
at the beginning : Clients ---> ISA(1) SP2 ---> ISA(2) SP2---> Internet in both case, compression was disable
then : Clients ---> ISA(1) SP2 ---> ISA(2) SP3---> Internet Here we got some problems and had to enable compression in ISA(2) like frodrigues2007 mentioned
Then we got many unreachable sites for client (like www.odu.de) following microsoft : http://support.microsoft.com/kb/927263 I installed SP3 on ISA(1), give me : Clients ---> ISA(1) SP3 ---> ISA(2) SP3---> Internet all with compression activated.
and now I have some corrupt sites. So, finaly, I'd like to disable completely the compression, but I don't really understand the Microsoft Note. Do I have to start the script "AccessRuleSendAcceptEncodingHeader" in ISA (1) AND/OR ISA(2) ?
It looks like you are facing the same problem as we did and as I described in my previous post (with only 1 ISA server in the path). Not sure if the script you mentioned is of any help. We kept the compression add-in enabled, but did not set any compression preferences. That, in our case, was leading to the most reliable (but not most efficient) situation, awaiting a bug fix, new SP or a better workaround.