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.
Related
I have a fairly detailed problem with which I hope someone can help. Basically, I have a .NET 4.0 website hosted on IIS7 that has some pages that necessitate URL rewriting. In order to implement these features, I have added a method to my global.asax that maps the extension-less URLs to their proper ASPX pages, and then performs a context.RewritePath in order to display the correct page.
Initially, I called this method from application_BeginRequest. However, we have some business necessary logging that occurs when Session_Start is called, and it appears that this logging is not always happening since the implementation of the URL rewriting in application_BeginRequest - Basically, every session gets logged in the DB, and after initial deployment of the URL rewriting, our session logs have dropped by about 20%, with no corresponding errors in the application log. At the same time, our IIS logs seem to be showing a relatively unchanged amount of traffic, so to my eyes, it appears that the sessions are not instantiating properly.
As a workaround for this issue, I moved the URL rewriting from application_BeginRequest to application_AcquireRequestState, so that this code won't fire until after I'm (mostly) sure that the Session has started. This works in my local dev environment and on our staging server (Windows Server 2008 - IIS 7 - .NET 4.5 Framework installed). In the Production environment (Windows Server 2008 - IIS 7 - .NET 4.5 Framework), I get 404 errors when trying to browse to the extension-less URL to be re-written.
I'm completely stumped - I've verified that I'm using the Integrated app pool, my web.config has the "runAllManagedModulesForAllRequests=true" attribute, my IIS features include HTTP redirection and static file compression, but nothing appears to be working. There's a hack that I found for using the Classic app pool, and creating extra script map handlers to handle wildcard URLs with no extensions, but I'm hesitant to put that in place in production.
Any help you can provide would be greatly appreciated. Thank you!
I would concentrate on why there was a 20% drop in session logs. Are you sure there wasn't also a drop in traffic? Are you using redirects for people coming to your site using the old .aspx Urls? Perhaps you received more 404 traffic that would not trigger the Session_Start? Did Google Analytics confirm that traffic maintained normal levels after the UrlRewite was put into place? You could also use IIS Log Parser to filter out static files and query 200 vs 404s from the log files to get a better sense of actual traffic.
We have a WCF service in our web application which is being called by browser through ajax(jquery and asp.net scriptmanager)
In this service some of the methods are WebGet and some of them are WebInvoke
Problem is now any request to WebInvoke method through asp.net scriptmanager is making request using http 'OPTIONS' instead of 'POST'. And webserver is going to deny this request as it don't allow OPTIONS
POST should be default for WebInvoke attribute when no method is defined.
We started having this problem since last couple of weeks just spotted today. We upgraded everything to .net 4.0 around same time so not sure .net 4.0 has something changed.
Also weird thing is everything works fine when using website like xyz.com we only see problem when using www.xyz.com
Any idea what it could be?
Edit: Ok got little closure
Problem is Asp.net scriptmanager does not allow cross site reference in ajax.
But wait we do not do anything that calls cross site.
What i found is when i use www.a.com some how js files generated by script manager wants to use a.com not www.a.com.
Any idea how to resolve this?
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
I'm developing a asp.net site (running .net 3.5 SP 1) and using UrlRewriter.Net (http://urlrewriter.net/) for urlrewriting.
The site is hostet on a Windows 2003 server with all servicepacks and so forth.
It runs IIS 6.
In order to enable url rewriting I've setup a wildcard handler for *, which means all requests are sent through the asp.net engine.
I've also enabled IIS compression feature - this works fine when I use the non-rewritten urls.
However it doesn't compress the rewritten pages.
I've added aspx, ashx and asmx as extensions to the metabase.xml, and set the proper compression level (9), etc.
The rewritten pages have .htm extension, so it shouldn't be because the extension is wrong.
Any ideas why this doesn't work ?
Probably because of the wildcard, IIS sends the request to ASP.NET, which further handles page generation etc. The compression happens to late in the pipeline, so it gets bypassed...
Unfortunately I haven't enough rep to leave comments.
If the issue is that compressions happens at the wrong time in the pipeline, I'd expect it didn't work for .aspx either (since everything is sent through the asp.net handler)
That being said, I guess it could handle .aspx earlier in the pipeline, as I believe the wildcard handler functions as a "last resort". Unfortunately on IIS 6 there is no changing the priority of handlers :-(
I guess I'll have to ask our administrator for a Windows 2008 server with IIS 7.
Today we tried to put an ASP.NET application I helped to develop on yet another production machine. But this time we got a very weird error.
First of all, from all the ASP.NET pages, only Login.aspx was working. The rest just show a blank screen when they should have redirected to Login.aspx. The HTTP response is 200, but no content.
Even worse - when I try to enter the address of some inexistent ASPX page, I also get HTTP 200! Or, when I enter gibberish in some existing ASPX page code (which should have been accessible without login) I also get HTTP 200.
If I enter the name of some inexistent resource (like asdasd.jpg), I get the expected 404.
The redirect to login page is written manually in Global.asax. That's because the application has to use some alternate methods of authentication as well, so I can't just use Forms Authentication. I would suspect that Global.asax is failing, if not for the working Login page.
Noteworthy facts are also that this machine is both a Domain Controller and has SharePoint installed on it. Although the website in question is listed in SharePoint's exception list.
I would check the following:
Is the application within a virtual application or its own site and not just a virtual directory?
Does the application have it's own App Pool? If it does not then is the app pool shared by apps in a different .net version.
Is the .net version of the application the correct one? 1.1 or 2.0?
Do the files in the file system have the correct permissions to be accessed via IIS?
Have you performed an IIS Reset?
Create a stand alone test.aspx page within your folder that just displays the date/time and check it works.
Make this single test.aspx page perform an exception (eg. divide by zero) and see what the outcome is.
More information required.
What Op Sys?
What mode IIS running under?
What version of .Net?
What version of SharePoint?
(Why are you using your DC as a web host?)
Does it work on the other production machines you've deployed to?
If so what is different between this machine and the working ones?
Did you deploy the same way?
Are you sure your hitting the right machine?
Are you sure your hitting the right web site?
What ISAPI components are installed globally and for the web site?
Is .aspx mapped to the ASP.Net ISAPI filter?
Do you have any HTTP Modules or HTTP Handlers configured?
Can you change the global aspx to write out some messages so you can be sure the piece of code you interested in is reaching?
Anything coming up on the IIS log or the event logs?
Addition:
What version of .Net?
By the sounds of it the .jpg request is being dealt with by IIS directly which is why you get the 404, but the .aspx request is being dealt with by something else which except for you login page, is always returning 200.
Assuming .aspx is wired correctly to .Net the the order of processing is based on ISAPI filters (high to low then global before site), then the ASP.Net ISAPI Extension (sorry I said this was a filter earlier but it's actually an extension). Then we get into the ASP.Net pipeline based on your .Net configs, and calls the HTTP Application (which includes your global.asax code), any HTTP Modules followed finally by a HTTP Handler. Your ASP.Net web forms are just fancy HTTP Handlers.
However, the request can be responded to and terminated from any point.
Since your code works on other machines though, I'm tempted to point a finger at SharePoint if it isn't installed on the working machines. Is this SharePoint 2007? That is also an ASP.Net application (I don't think 2003 was).