Jan 13

Written by: Renegade
Friday, January 13, 2006 12:00 AM

I recently had a few people tell me that downloads weren't working for them. Strange... I was VERY careful to test things pretty well and made sure that things worked. Heck. They worked really well. But that didn't change the fact that some people couldn't download some files - EXE files to be precise.

It only affected a very few people. One person let me know their browser version - IE 6. Worked for me on the same platform & same browser... Even wierder... But perhaps I should just cut to the chase.

I had enabled compression in IIS in the metabase.xml file. The web site was BLAZING fast. But that was the source of the problem. A simple change to the default fixed it.

The IIS metabase.xml file is in C:\WINDOWS\system32\inetsrv by default. The default values for the nodes on compression are:

< IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/deflate"
  HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
  HcCreateFlags="0"
  HcDoDynamicCompression="TRUE"
  HcDoOnDemandCompression="TRUE"
  HcDoStaticCompression="FALSE"
  HcDynamicCompressionLevel="0"
  HcFileExtensions="htm
   html
   txt"
  HcOnDemandCompLevel="10"
  HcPriority="1"
  HcScriptFileExtensions="asp
   dll
   exe"
 >

And in this node:

< IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/gzip"
  HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
  HcCreateFlags="1"
  HcDoDynamicCompression="TRUE"
  HcDoOnDemandCompression="TRUE"
  HcDoStaticCompression="TRUE"
  HcDynamicCompressionLevel="0"
  HcFileExtensions="htm
   html
   txt"
  HcOnDemandCompLevel="10"
  HcPriority="1"
  HcScriptFileExtensions="asp
   dll
   exe"
 >

That's easy enough. To make a site faster, you just add the file extensions to the HcScriptFileExtensions or HcFileExtensions attributes, set the compression ratio in HcDynamicCompressionLevel and voila! (Well, almost that easy, but this isn't about enabling compression - it's about fixing it after you've buggered it...) Your web site is BLAZING fast.

However, if you're serving downloads like setup programs with an EXE file extension, you're in for a nasty suprise.

EXE is included in HcScriptFileExtensions - the section for dynamic web pages. This will also compress your EXE downloads as well. Which can't hurt too much... right? Wrong. When dynamic files are compressed, they aren't cached like static files are. The compression is all done on the fly. This is more expensive in terms of CPU, but that's not where it hurts.

Since the file is being compressed and sent out on the fly, the CONTENT-LENGTH header for the file is absent. This will cause the download dialog in IE to display a message telling the user that the file size is unknown. The download progress just cycles around until the download it done, and you only know how much is downloaded - not how long it will take or how large the file is. A bit frustrating, but no big deal.

However, it also causes some IE configurations to abort the download entirely. That's completely unacceptable.

The solution is to just remove that EXE from the HcScriptFileExtensions attribute as it's not meant for downloads - it's meant for sites that are programmed in C (or whatever language) that use EXE files to return dynamic pages.

I had spent a few hours trying to track the problem down, and finally found it after sorting through HTTP headers and all sorts of other fun stuff. So, if you've enabled compression for IIS, and your visitors are downloading EXE files, make sure to remove that entry for both GZIP and DEFLATE in the IIS metabase.xml file.

BTW - Thankfully a user let me know that the download worked after a couple emails. It wasn't here at Renegade Minds as the problem is pretty rare and only had 1 report here. At the day job, the ALTools web site has a LOT more traffic, and only received 2 reports.

Cheers,

Renegade

Tags: