Earlier this week Port80 Labs identified a new issue with Symantec Norton Internet Security version 2006 software running on Web clients that are sent compressed content (read post).
The real problem arises when Cold Fusion server (particularly, in our testing, CFMX 6.1) is added to the mix, along with compression. Something about how CF reassembles its own responses (those it is responsible for serving) seems, in conjunction with compression, to create response entity that the Symantec Norton Internet Security 2006 (NIS 2006) decompression engine on the client side cannot properly handle.
The result of this combination can be quite damaging to a site, like uncompressed content being rendered in the browser:
Or, potentially worse, the browser mistakenly attempting to download the page as a compressed file like a WinZip file (which is much different than transparent HTTP compression):
One of our clients tried to get their browsers running NIS 2006 to change their settings to using the older HTTP 1.0 protocol for browsing, which kills the issue but also kills compression... The reason why changing the client to HTTP 1.0 avoids the issue is because doing this circumvents compression altogether. The Accept-Encoding header is never sent in the request and so the response is not compressed. One of the three elements necessary for reproducing the issue (Cold Fusion + compression + NIS 2006 on the client) is removed.
In principle, therefore, clients running NIS 2006, and asking for compressed content (i.e., using HTTP 1.1 requests) from a server that is compressing data when asked to do so, should not be sent compressed data, despite having asked for it. There should be an exclusion for these particular clients.
The difficulty with that is that NIS 2006 does not (as prior versions did) show itself to the server (and therefore to httpZip or any compression tool) by dashing out any headers *in the request*. Operating only on the response, it seems to be undetectable to the server.
That makes the "HTTP 1.1 compression + NIS 2006 + CFMX" interoperability bug an unusually difficult one to deal with… For the moment, we do not have any solution for it, besides advising clients/browsers running NIS 2006 to use HTTP 1.0.
Closer examination of the compressed response stream coming back from CF Server might yield some clue about how to change that response in such a way as to prevent the Symantec Norton Internet Security 2006 failure on the client (a possibility we will investigate). But we should caution in advance that it is also possible that there will be nothing httpZip can do to correct this issue, since interoperation with another process on the server (Cold Fusion) and an unannounced process on the client (NIS 2006) seems to be necessary to create the failure condition.
Please feel free to contact Port80 Support for more details, fellow IISers.
Cheers,
Port80