I've used the UrlRewriting.Net module for a couple years now without any problems in Windows XP and Windows 2003. I just recently upgraded my home PC to Windows 7 and started developing a new website.
The plan was to use .html extensions and rewrite them to their .aspx counterparts using the UrlRewriting.Net module. Everything works flawlessly in VWD 2008, but when I try running it through IIS7 it is a different story.
When I try to access a page via the .html rewrite I can no longer access Page.User; it keeps returning null. If I hit the page using it's .aspx extension, Page.User is correctly populated. I should also mention that I have a LoginView controller in my Master Page and it suffers from the same symptoms: When accessing via .html extension it shows the AnonyousTemplate; When using .aspx extension it properly shows the LoggedInTemplate. I'm guessing the two are related.
[Note: I've also tried extensionless URLs and they exhibit the same problem]
The only way I've gotten it to work is to switch the application pool to Classic, which then requires me to add an ASP.Net ddl handler for the .html extension [otherwise it is handled by the StaticFileHandler and comes up as a 404 error]. However, I'd like my web app to run properly for people without having to fiddle around with IIS.
So I am left with several questions:
Does anyone have ideas as to why Page.User always equals null for .html => .aspx rewritten pages?
Why does it work in VWD 2008, but not IIS7?
What changed from IIS6 => IIS7 that could have caused this?
Any other thoughts on workarounds?
[Note: I just tried a .aspx => .aspx rewrite and it did not exhibit the problem. Not really what I want, but thought I should mention it.]
Just had a breakthrough with the UrlRewriting.Net module. This makes it work in Integrated Mode in IIS7:
<modules runAllManagedModulesForAllRequests="true">
After figuring it out I did a search on "runAllManagedModulesForAllRequests" and the first thing that popped up was Scott Guthrie's blog which actually talks about using it for this purpose.
Another approach that seems to work is to remove the Session module and readd it leaving the "Invoke only for requests to ASP.NET applications or managed handlers" checkbox unchecked. It looks like this in the web.config file:
<system.webServer>
<modules>
<remove name="Session" />
<add name="SessionManualAdd" type="System.Web.SessionState.SessionStateModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</modules>
</system.webServer>
It seems the problem is that the Session module doesn't execute for say '*.htm' files when HttpContext.RewritePath is used, but removing and readding the module in this fashion causes the Session handler to be executed for the request.
This solution was suggested on the thread below. Unfortunately Microsoft chose not to explain the reasoning behind this behavior fully:
http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7
Microsoft included a fix for this issue (at least for extensionless urls) in Service Pack 1 for Win7 and Windows Server 2008 R2:
http://www.microsoft.com/download/en/details.aspx?id=5842
Also available as a hotfix: http://support.microsoft.com/kb/980368
After this patch is applied, ASP.NET 4 applications can handle requests for extensionless URLs. Therefore, managed HttpModules that run prior to handler execution will run. In some cases, the HttpModules can return errors for extensionless URLs. For example, an HttpModule that was written to expect only .aspx requests may now return errors when it tries to access the HttpContext.Session property.
After applying SP1 or the hotfix, no web.config changes are needed to make the session and forms auth work for extensionless URLs rewritten to asp.net pages/handlers/etc.
I don't know if this fixes anything for rewrites to static file extensions like .htm. My guess is, probably not. I would try to avoid setting runAllManagedModulesForAllRequests="true" in production environments, because it adds unnecessary overhead on static file requests.
Related
I have taken over the maintenance of a production website at a new job that is written in ASP.NET 4 Webforms and that runs on IIS 6 on Windows Server 2003. I am not familiar with Webforms nor managing IIS...so I am kind of working things out as I go here.
I have done several deployments to our production server which have worked fine, but am now setting up a test environment that is identical, just a different IP address/domain, so we can properly test changes first.
I have a problem where on this test site any URL that does NOT end with a reference to a file (always .aspx on this site) will return a 403 error on this server. For example http://users.test.oursite.com/admin will always return a 403 error when logged into the site. It should be redirecting to http://users.test.oursite.com/admin/organisation.aspx. Having an MVC background I am not even sure how this happens...but it does in production.
Browsing links within the site is fine as they always reference an .aspx file. Manually typing URLS that reference an .aspx file is fine, just not when the URL does not contain a file. This is not a problem on the production server.
As I said, I am not familiar with WebForms or managing IIS itself...so I have kind of run out of places to look.
Is there anything that comes to mind that I should be looking at that could be causing this problem?
In WebForms typically there is no routing involved.
You need to either provide a full path on the URL ending with .aspx OR
setup default documents for your website. (Index.aspx, Default.aspx etc.)
http://www.iis.net/configreference/system.webserver/defaultdocument
OR
<configuration>
<system.webServer>
<defaultDocument enabled="true">
<files>
<add value="home.html" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
Default documents can be setup in IIS Properties or via web.config.
Otherwise you need to provide the full path.
And because you haven't setup the DirectoryBrowsing (in IIS), you get a 403 Error when you try to access the Directory.
Enable the Directory Browsing option in IIS (not recommended) if you want this error to go away.
I've created an httpModule to handle URL remappings, and it works great on my test system. A request for www.mydomain.com/Some_Fancy_URL gets rewritten to www.mydomain.com/some.aspx?fancy=23 and so on.
When I deploy to the actual web site, I'm getting the default IIS 404 page though.
After doing some research online, it would seem that I need to setup "Wildcard Mapping" in IIS 6 to get the request past IIS and in to my httpModule. The problem is that the site is hosted on a shared server, so it may not be possible to get the ISP to make that change.
My question is, can't I use an httpHandler to tell IIS how I want these requests handled? For example:
<httpHandlers>
<add path="*.aspx" verb="GET,POST" type="System.Web.UI.PageHandlerFactory" validate="false"/>
</httpHandlers>
It would seem like adding this to my Web.Config should tell IIS to stop validating the existence of .aspx files, and just pass the request along for me to process. It doesn't work though.
Any suggestions?
The problem with IIS 6 and ASP.NET is that they're aren't integrated. IIS needs to be told about ASP.NET via script mappings (.aspx, .asmx, wildcard and so on).
None of your web.config configuration settings will influence IIS because web.config is there to configure ASP.NET's behaviour, not IIS. IIS has no knowledge of web.config.
Unless you can hand off a request to the ASP.NET pipeline (via a script map) nothing will happen and all your web.config settings will be ignored.
With IIS 7 the story is quite different. In IIS7, ASP.NET and IIS are closely integrated and share the same pipeline thus permitting you to achieve the result you're looking for.
The alternative may be to find out if your hoster runs a URL rewriter such as ISAPI_Rewrite on their servers. That way you could rewrite urls without having to map a wildcard scriptmap to IIS6.
Through some trial and error, along with more web searches, I found a solution. It essentially parallels Kev's answer.
IIS won't treat a request as .NET unless it has a known file extension (.aspx, .ascx, etc.). When I send along something like www.mydomain.com/anything it looks for a file or folder named "anything", and when it doesn't find one, it just drops off to the default IIS 404 handler.
That's where I took over. I changed IIS 6 to forward 404 problems to /404.aspx. I then created that page with a generic "Your file wasn't found" message in the same style as my web site.
Here's the good part: Now that IIS is sending 404's to a .NET page, the custom httpModule I created is getting fired. The request is for 404.aspx, but IIS is nice enough to also append the original URL as well. You get something like:
www.mydomain.com/404.aspx?404;http://www.mydomain.com/anything
This allows me to parse the request in the httpModule, and rewrite as needed!
I am trying to implement the TinyMCE Spellcheck plugin that uses GoogleSpell. The thing is I am trying to install it in an MVC environment.
I started by referencing the .NET class Library DLL (MoxieCode.TinyMCE) in my project.
Then, I added this code to my web.config:
<system.webServer>
<handlers>
<add name="TinyMCE" verb="GET,HEAD,POST" path="TinyMCE.ashx" type="Moxiecode.TinyMCE.Web.HttpHandler,Moxiecode.TinyMCE" />
</handlers>
<!--previously existing rules-->
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
I then added these lines to my tinyMCE.init({}); call:
plugins: "spellchecker",
theme_advanced_buttons3: "spellchecker",
spellchecker_languages : "English=en",
spellchecker_rpc_url : "TinyMCE.ashx?module=SpellChecker",
These steps are outlined in the tutorial here. I then followed instructions from this stack overflow post which recommended the following modification to global.asax to make it mvc friendly:
routes.IgnoreRoute("TinyMCE.ashx");
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
Everything seems fine accept that when I browse to /TinyMCE.ashx i get this error:
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /TinyMCE.ashx
Why can't asp.net mvc process that url?
Make sure the handler is being applied at the correct element in the web.config.
IIS supports 2 types of modes, an integrated mode and a classic mode.
The classic mode is the how versions previous to IIS 7 worked. Depending on that, you put the handlers in the web.config section that applies to asp.net, or in the section that is picked by IIS directly.
After a fair bit of frustration I stopped messing with it on localhost in VS 2010. I suspected that it was a problem relating to IIS configuration, so I uploaded the site to a sub-domain of the live server. It worked without any problem.
I'm not sure why the code didn't work on localhost but evidently, the steps I followed to execute TinyMCE .NET and GoogleSpell were correct because they work on the live server.
I'm trying to get a custom handler to work for a specific URL (or set of URLs) in ASP.NET 3.5.
The handler doesn't actually do anything significant yet - it just logs the request. I can post the code if anyone things it's relevant, but I really don't think it's being called at all. (In particular, for normal exceptions I get a custom error page and logging... here I'm just getting the vanilla IIS 404.)
Here's the relevant bit of the web.config file:
<system.web>
<httpHandlers>
<add verb="GET,POST" path="*.robot" validate="false"
type="CSharpInDepth.Wave.RobotHandler, CSharpInDepth"/>
</httpHandlers>
</system.web>
(Obviously there's other stuff in that section too, but I don't think it's relevant.)
Locally, running under the dev server, it works fine. On my real box, I always get a 404. Everything under the web site directory itself is the same (replicated via svn). That includes the bin directory containing CSharpInDepth.dll, which I've verified contains CSharpInDepth.Wave.RobotHandler.
I try to fetch http://csharpindepth.com/foo.robot and just get a 404.
I've tried with and without the assembly name, specific URLs or wildcarded ones... nothing's working.
I'm sure I've just missed some simple flag somewhere in the IIS configuration, but I'm blowed if I can find it...
EDIT: It's IIS version 6. Attempting to add *.robot to the ISAPI filter now...
Well if the hosting box is IIS7 in integrated pipeline you need to add it into the other bit of the config:
<system.webmodules>
....
<modules>
<add name="RobotHandler" type="CSharpInDepth.Wave.RobotHandler, CSharpInDepth"/>
</modules>
....
</system.webmodules>
If it's IIS6 then you'll need to map *.robots to the ASP.NET ISAPI DLL.
(For the non-Skeets you do this as follows)
Open up IIS admin.
Right click on
the Web site you want to configure
and select Properties form the
context menu. This will display the
Web Site Properties dialog.
Select
the Home Directory tab and click the
Configuration button. This will
display the Application
Configuration dialog box.
Click
Add.
Select the aspnet_isapi.dll
from the .NET framework directory,
the extension you want mapped and
either All Verbs, or just the ones
you want to map.
Click ok.
Jon,
You'll have to configure the IIS script mappings to pass *.robot to aspnet_isapi.dll.
We are using the Intelligencia URLRewriting module for asp.net with version 2.0 of the framework and IIS6. Our URLs typically have no extension.
I understand that IIS6 cannot really deal with this situation without a blanket wildcard (which causes other problems).
However, it works! Sometimes. At other times (e.g. on one dev's machine, and on my machine when I point a different virtual directory at the app) it doesn't. By "it doesn't work" I mean the configured HttpModules never even get hit.
Can anyone explain this?
Thanks.
So it turns out what was happening was the following:
request comes in to (say) http://website/products/productid
IIS can't find this hence we get a 404
by chance we have a custom error page set up in IIS for 404s
this error page sticks the referring URL on the end of the 404 error.aspx page
so we get a redirect coming into asp.net along the lines of:
http://website/error.aspx?404;http://website/products/productid
our URLRewriting regexes were now set up in such a way that they discarded the error.aspx bit and dealt with http://website/products/productid as if it were the actual URL
so asp.net renders http://website/product.aspx?id=productid as requested!
I guess this could prove to be a useful kludge for someone, but we're moving to an isapi filter. One heads-up is that this will by default lead to a tight loop of redirects!
If you run a site using the Visual Studio development web server all requests will be handled by asp.net so your HttpModule will run.
On IIS6 this should not happen unless it is set up to forward the requests to asp.net.
Are you sure that when "it works" you aren't running under the Cassini development web server included in VS.NET ? Because extensionless wildcards do work under Cassini, which can be very confusing to say the least.
If you are using an IIS6 with ASP.net 4.0, you must specify and register the modules like this:
<system.web>
<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
not
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
</modules>