I've tried to setup compression (both dynamic and static) in IIS7 for my local system, but when start my ASP.NET site using the debugger, YSlow tells me that all of the files (aspx, js, css, etc.) are not compressed. Any ideas? I really want to test this before I make changes to the production server.
Are you using Cassini as your server? If so it does not support compression that I know of.
You might try using Fiddler to see what the accept headers are that are being sent back and forth:
Fiddler
Enable compression on dynamic content in IIS7
Problem with GZIP transfer using webrequest
Related
I'm attempting to enable gzip compression on my web server. I've installed the dynamic compression module on the server and enabled it in IIS. Now I'm attempting to specify dynamicTypes to include application/json. I followed these steps. I successfully added the dynamics types at the server level. When I checked my app, I noticed the response headers still did not include gzip. I then went back into IIS to confirm the configuration editor settings at the server were inherited for my site. At the site level, I do no see an httpCompression node in the drop down under the system.webServer section. A colleague with IIS10 (I have IIS8) is able to see the system.webServer/httpCompression node.
Any idea why I'm not seeing that node? I believe this is responsible for gzip not working in my setup.
That's strange you don't see it. Try reinstalling compression modules(dynamic and static). Apart from that make sure you have below under your system.webServer
<urlCompression doDynamicCompression="true" doStaticCompression="true" />
I just figured out what the problem was. First, there seems to be a difference between versions of IIS (IIS6 and IIS10 in my case) in that some (newer) versions have an system.webServer/httpCompression on the site, not just the server. I thought that was the reason dynamic caching seemed to not work on our dev server but did work on a colleague's machine with IIS10.
It turns out the reason I wasn't seeing a gzip encoding reference in the response headers is because of IE, IE10 to be exact. Our dev environment currently has a certificate problem and you can only open the app in IE. I have IE10 and it does not appear to display any information on the response headers about compressed encoding. I had my colleague with IE11 hit our app in the dev environment and he sees the gzip encoding reference in the response headers.
This is why I hate IE...
I don't have access to IIS Server as I am hosted on a shared hosting. I don't have access to remote IIS manager or the command prompt on server.
Now, my question is, Is it possible to gzip my asp pages? I am hosted on an IIS 7 server.
Any type of file can be compressed including ASP Classic pages. However, HttpCompression is configured on the web server where the server identifies which extensions should be compressed. If .asp files have been marked for compression, then it should be the case that the web sever will add the Content-encoding: gzip header for you.
Yes, you'll have to use global.asa file for handling Application_PostRequestHandlerExecute event
Next gzip or whichever you prefer compression is required, that's available through library functions for asp.net, however for classic try yui compressor or best is implement the compression code manually. An example of consuming it is at
http://www.west-wind.com/weblog/posts/2011/May/02/ASPNET-GZip-Encoding-Caveats
Finally, remember to append content-encoding header client may not cross-examine for compression otherwise.
First, a little background. I have written a custom HTTP compression module for ASP.NET. My development machine has Windows 7 Ultimate, which comes with IIS7. My production environment uses IIS6.
The problem I'm having is, Resource Expert Droid (redbot.org) tells me that I need to add a header to my response to properly support compression: "Vary: Accept-Encoding"
On IIS7 in integrated mode, it works properly. However, in classic mode, which is how my application ultimately runs, I cannot get my code to output this header using any of Response.AppendHeader(), Response.Cache.SetVaryByCustom(), or Response.Cache.VaryByHeaders.
I'm using a wildcard handler mapping, so ASP.NET sees all requests even in classic mode.
I realize you said you tried this already, but here's the usual approach:
this.Response.Cache.SetVaryByCustom("Accept-Encoding");
You might try calling that method late in the life cycle, such as from End_Request in an HttpModule.
If that doesn't work, unfortunately, in IIS6, you will need to use an ISAPI to set custom HTTP headers.
FWIW, the built-in compression system should set that header automatically for you.
We've got a classic ASP application that is putting out some very large reports, where the resulting HTML is several MBs. We've made a lot of progress in trimming this down by reducing extraneous HTML, but I'd like to know if there's any way to enable GZIP compression on these dynamic .asp pages. I'm sure compressing them would be an enormous benefit to the file size.
All of the GZIP compression information I've seen only talks about supporting files or .aspx pages.
Thanks.
Sure, that's just a matter of turning on compression in IIS. See this MSDN page for example.
I recommend using HttpZip from Port 80 Software. It basically just enables compression in IIS but from a GUI instead of getting into the metabase. I used it in a web-farm for a big enterprise ASP application.
I have an ASP.NET webforms application (3.5 SP1) that I'm working on, and attempting to enable gzip fpr HTML and CSS that comes down the pipe. I'm using this implementation (and tried a few others that hook into Application_BeginRequest), and it seems to be corrupting the external CSS file that the pages use, but intermittently...suddenly all styles will disappear on a page refresh, stay that way for awhile, and then suddenly start working again.
Both IE7 and FF3 exhibit this behavior. When viewing the CSS using the web developer toolbar, it returns jibberish. The cache-control header is coming through as "private," but I don't know enough to figure out if that's a contributing factor or not.
Also, this is running on the ASP.NET Development Server. Maybe it'd be fine with IIS, but I'm developing on XP and it'd be IIS5.
Is it only CSS files that get corrupted? Do JS files (or any other static text files) come through ok?
Also can you duplicate the behavior if you browse directly to the CSS file?
I've only enabled compression on Windows 2003 server's IIS using this approach:
IIS → Web Sites → Properties → Service tab, check both boxes
IIS → Web Service Extensions → Right click, Add New
Name
Http Compression
Required Files
%systemroot%\system32\inetsrv\gzip.dll
IIS → Right click top node, Internet Information Services, check Enable Direct Metabase Edit
Backup and Edit %systemroot%\system32\inetsrv\MetaBase.xml
Find Location ="/LM/W3SVC/Filters/Compression/gzip"
Add png, css, js and any other static file extensions to HcFileExtensions
Add aspx and any other executable extensions to HcScriptFileExtensions
Save
Restart IIS (run iisreset)
If you have a Windows 2003/2008 server to play with you could try that approach.
If you will be deploying on IIS 6 or IIS 7, just use the built-in IIS compression. We're using it on production sites for compressing HTML, CSS, and JavaScript with no errors. It also caches the compressed version on the server, so the compression hit is only taken once.