This is a generic error - however, one of the most common causes of this error being returned is that the origin content server (OCS) has responded with data that does not match the MIME type that the web server indicated in its response headers. The most common occurrence of this (and an example of such behavior) is a web server whose HTTP response headers indicate that it will be responding with a gzip compressed object, but the content is actually text. As a security device, ProxySG will not blindly provide such data to the client and instead will return the Appliance Error exception to the client.
Note that in SG 220.127.116.11 a new exception (content_encoding_error) has been created to more properly report the scenario described above to the end user.
There is no "fix" on the proxy for this behavior as the web server is behaving incorrectly. However, in the specific scenario described above, if you want to allow the content from the web server to be delivered to the user you can implement the following policy based workaround. This workaround removes the header in the client request indicating that the client can receive encoded content and instead forces the server to respond with the file in its original form.
- Create a new Web Access Layer
- In the "Destination" column of the first rule, set to either the Request URL object of the site in question or a category object containing the list of URLs you wish to match to this rule.
- In the "Action" column, create a new object. Use a "Control Request Header" object. Select "Accept-Encoding" from the Header Name list.
- Leave the radio button at its default of "suppress".
- Press OK and install this new policy.
CPL example: (Replace bad-encoding-site.com with the name, or category of the site experiencing the problem.)
define action ControlRequestHeader1
end action ControlRequestHeader1