Been a while since a dedicated ISA post, so Happy New Year to my ISA-focused readers!
I spotted this post in my ISA Server watch list, from the new Port 80 Software blog.
As they mentioned, we've published the mother of all KB articles on how the HTTP Filter in ISA 2004 behaves with compressed (Gzip encoded) content:http://support.microsoft.com/default.aspx?scid=kb;en-us;838365
The really, really short version is that for Web Publishing rules, the IFPCWebPublishingProperties::SendAcceptEncodingHeader property can be used to toggle compressed content on, but ISA won't be able to inspect the contents of compressed traffic thereafter - only the headers. So, you get compression at the cost of inspection (and caching of the compressed content, for the same sort of reason).
The OWA publishing wizard enables SendAcceptEncodingHeader automatically for OWA rules, but if you set your own "faux OWA" rule up with the Web Publishing Wizard, the property isn't set.
My initial reaction to anything with a :: (blup blup) in it is "oh no! I have to re-learn C++!", but there's no cause for alarm - ISA is easily scripted- just grab the SDK, and take a look through the samples. If you want to throw your own script together to toggle this property, I've posted an example below. Of course, the truly devious will just create an OWA rule, then re-purpose it to their own needs :). As always, unsupported, and there's more than one way to skin a cat, mileage may vary, etc.
The code is here:
''''' This script is a SAMPLE ONLY and is provided as is, without warranty
''''' The user variable is at the bottom of the script, called "rulename"
Set root = CreateObject("FPC.Root")
Dim firewall ' An FPCArray object
Dim policyrules ' An FPCPolicyRules collection
Set firewall = root.GetContainingArray
Set policyrules = firewall.ArrayPolicy.PolicyRules
for each rule in policyrules
if rule.Name = targetrulename then
wscript.echo " Found target rule: " + rule.Name
if rule.WebPublishingProperties.SendAcceptEncodingHeader = false then
wscript.echo " SendAcceptEncodingHeader WAS DISABLED, now ENABLING."
rule.WebPublishingProperties.SendAcceptEncodingHeader = true
elseif rule.WebPublishingProperties.SendAcceptEncodingHeader = true then
wscript.echo " SendAcceptEncodingHeader WAS ENABLED, now DISABLING."
rule.WebPublishingProperties.SendAcceptEncodingHeader = false
wscript.echo "Saving Rule..."
''''' Program starts here
rulename = "Test Headers Rule" ' Should be unique
ToggleClientAcceptHeaders(rulename) ' set the option for all rules with this name
This gets hit in some scenarios from time to time - I hit this with an OWA deployment where the OWA wizard hadn't been used to configure the publishing rules. The effect in that case was to disable ZIP files being downloaded through the ISA Server, as they were sniffed to be Zip encoded, and disallowed (the Firewall Logs showed something about the HTTP filter dropping the traffic).
Tiernans Blog » Enabling compression to pass though ISA 2004
>ISA won't be able to inspect the contents of compressed traffic thereafter - only the headers
Erm, maybe I'm missing something, but why not? Just decompress it and look at the data. It ain't encrypted.
You're not missing anything; it just wasn't designed to do that (yet?).
It's something that a Web Filter could do in conjunction with ISA, so that ISA inspects the decompressed content before the filter re-encodes it.
There was some (outside MS) talk of someone coding something like this a while back, but I don't think it ever actually happened.
Squeeze those bits out!