meaning of same types for static and dynamic content in iis http compression

Question

I am looking at the ApplicationHost.config file in IIS server to understand the configurations of Http Compression.

I see the following code:

<httpCompression
      directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
   <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
   <dynamicTypes>
      <add mimeType="text/*" enabled="true" />
      <add mimeType="message/*" enabled="true" />
      <add mimeType="application/javascript" enabled="true" />
      <add mimeType="*/*" enabled="false" />
   </dynamicTypes>
   <staticTypes>
      <add mimeType="text/*" enabled="true" />
      <add mimeType="message/*" enabled="true" />
      <add mimeType="application/javascript" enabled="true" />
      <add mimeType="*/*" enabled="false" />
   </staticTypes>
</httpCompression>

(taken from: https://learn.microsoft.com/en-us/iis/configuration/system.webserver/httpcompression/)

And my question for you is:

What does it mean to have the same mimeType in both dynamic and static types?

For example from the code I gave we see application/javascript in both sections. now lets say both dynamic and static content compression are enabled, what will happen when we serve an Http Response with Content-Type application/javascript?

Answer 1

Content served by IIS is either static or dynamic. For the most part, if your content is served by a handler such as ASP.NET or Classic ASP, then it falls under the dynamic bucket, if it is a file read straight off the disk, it a static. The example you give obviously doesn't matter because if application/javascript is served, and is enabled by both, then it is eligible for compression. A better example is to say that if the javascript is served thru the static file handler (i.e. the javascript file is from a .js file on the disk) then it will change the static file handler to see if compression is enabled and may compress it. If the javascript comes from some call to script.axd or some other "dynamic" handler, then it will check the dynamicTypes.

So you might ask why two sections? The reason is simply that static files can be compressed and then cached because the files are, well, static. Therefore, we can be much more liberal with our static caching rules because the file can be compressed for the first person who requests it and then cache that compressed copy. Future requests to that same file can be served directly out of the cache. Of course the system handles any modifications that may happen to the file an updates the cache.

With dynamic content, well, that file may be different for every request, every user, etc. As result, IIS doesn't make attempts to cache the compressed copy and simply compresses it each time.

Hopefully that's enough info to get you started. Side note, with static compression it doesn't actually compress for the first user (generally) and it needs a couple people requesting before it goes thru the effort of compressing the content.