I am attempting to do some domain redirects on one of the sites on my server (Server 2003, IIS6), but the Extensionless URLs feature of .Net 4 keeps tacking on that eurl.axd/GUID before the redirect. I found some info on that here.
I would just disable this feature, as described here, but I am pretty sure this will impact an MVC .Net site I also have set up in IIS (because MVC uses extensionless URLs).
Can someone please assist me in finding other options? Is there a way to just remove the eurl.axd/GUID from the URL, via an IHttpModule? I haven't been able to find an example of anyone doing this or something similar.
Ok, I seem to have fixed things on my own. Originally I had both my websites set up in IIS under the same App Pool. I separated them into different app pools, made sure they were both set to .Net 4, and everything started working. Now when users are redirected from one domain to another, the eurl.axd/GUID does not get tacked on to the end of the URL.
Related
I'm developing an ASP.Net MVC application in C#, and it is hosted in an IIS server. Right now the client asked me to have a CMS on the same app url, that will be used to serve the public pages.
I have looked for ASP.Net MVC CMS apps and could not find anything that would be easily integrated with the current application, so I choose to do it by changing the server configuration.
What I need is:
Custom App:
exampleappurl.com/User
exampleappurl.com/Company
etc
CMS:
Any other URL, including "index" (exampleappurl.com)
Can I do it using any kind of Rewrite rule? Or IIS configuration? What is the best solution?
Thanks in advance!
On IIS6, there is a feature called 'host headers', that does exactly this: several websites may share the port 80, and the request goes to one of the sites its URL points to.
http://www.it-notebook.org/iis/article/understanding_host_headers.htm
http://technet.microsoft.com/en-us/library/cc753195(v=ws.10).aspx (this one is about IIS 7)
I noticed that asp.net 4.0 now installs a top-level isapi plugin (in iis6), such that it can inspect every request coming to the server. Should this now allow us to run MVC applications with extensionless URLS and have the aspnet isapi process them correctly without requiring the wildcard mapping (and avoid the performance penalties associated)? I havent found anything written about this yet, and havent had time to investigate. Thanks
ASP.NET 4.0 installs the C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll ISAPI filter in order to map incoming request to the new CLR, but this filter is not registered as wildcard mapping but is associated only with known extensions. It does not intercept every incoming request. If you want to have extensionless urls you will need to perform the same steps as for ASP.NET 2.0 but use the new ISAPI filter instead.
found the answer:
Link
appears that there are new features in asp.net 4.0 that enable extensionless urls. I need to do more research on this to find out how to utilize it.
Basically it appends /eurl.axd/GUID to each routed request, which then gets passed to aspnet_isapi.dll to be processed. the eurl.axd is then removed at this point.
The problems Im having is how these interact between my Ionics rewriter IIRF software and this new .net rewriting... they seem to be interfereing with each other at times.
We are getting ready to do a an initial deployment of an ASP.net MVC app on IIS 6 running on Windows Server 2003. We've been reading about performance issues involving the use of extenionless urls in MVC applications specifically in the case of removing the '.aspx' extension from the controller portion of the url.
Has anyone who has deployed an MVC app in the past experienced any performance degradation in this area? Was it noticeable, and was it worth it for having the cleaner URLs? Our application will rarely have to deal with more than 1000 or so concurrent users.
Edit: Thanks for all the responses, it's working quite well, although there are a few strange requests going through as some people mentioned, I think we can work around these using the suggestions mentioned here.
We recently deployed an app that received approx. 20 million page views over a 3 month period using the IIS 6 wildcard mapping setup and had no performance issues. We did host most of our images on a CDN, but other static content was served directly from the site.
For what it's worth, IIRC, the asp.net handler will pass requests for static file types back to IIS through a default handler for processing. The only practical performance hit is the time during that process that a worker thread is occupied identifying and transferring the request. In all but the most extreme scenarios, this is too trivial to matter.
As an extra note, we load tested the application I mentioned prior to going live and found that it could handle nearly 2000 static requests per second and around 700 requests per second for pages that involved database activity. The site was hosted on 4 IIS 6 servers behind a ZXTM load balancer with a 1GB internet pipe.
Here's a link with some good advice on the whole static file handling business:
http://msmvps.com/blogs/omar/archive/2008/06/30/deploy-asp-net-mvc-on-iis-6-solve-404-compression-and-performance-problems.aspx
The problem with not using extensions on IIS 6 is that you don't want static requests to go through the ASP.NET stack. If all of your static requests come from one (or two...) subfolder(s), you can exclude them. This should fix the performance issue.
Quoting from the linked post:
Now, to remove the wildcard map on the
/Content subdirectory, open a command
prompt, go to c:\Inetpub\AdminScripts,
and run:
adsutil.vbs SET /W3SVC/105364569/root/Content/ScriptMaps ""
… replacing 105364569 with the
“identifier” number of your
application. (Also, you could replace
“Content” with the path to any other
directory.)
We ran a fairly busy site with IIS6 wildcards on for extensionless URLs and although we never noticed much of a performance hit, we did have a little hack that worked quite well:
For all folders that contained only static files, like /css, /images, /scripts etc, in IIS we set them as their own application, and disabled the wildcard setting, which meant IIS handled the requests rather than routing through ASP.Net.
Url rewriting can help you to solve the problem. I've implemented solution allowing to deploy MVC application at any IIS version even when virtual hosting is used.
http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx
Instead of serving all the requests by ASP.NET, you could specify e.g. mvc as the extension (say index.mvc) and map that extension to aspnet_isapi.dll in IIS 6.
This means only known extenions will be processed by asp.net, others like static files stay the same as before i.e. served by IIS itself.
How can I let web users create a subdomain on the fly for Windows Server 2008 for my website?
My application is in MVC 1.0 and ASP.Net 3.5 with C#.
Take a look at this... http://blog.maartenballiauw.be/post/2009/05/20/ASPNET-MVC-Domain-Routing.aspx
The most common way (in terms of theory) is to map *.domain.ext to your one web-application. It itself parses the request to see which subdomain is being used and therefore which "site" to show.
In practice, I'm not sure how simple this is with IIS or ASP.NET. When I still used ASP.NET, I used UrlRewritingNet.UrlRewrite. It was light-years ahead of the competition two years ago, and it still looks a pretty handy thing to have in a fight now.
If you just want to map wildcard you do that in IIS (and in the DNS), then you can parse the requested url to get the subdomain. Otherwise Clarify the question.
As a dev team, we're looking to switch to asp.net MVC and I've heard rumors about IIS 6 not being able to support all of the MVC functionality. Is this true? Is there any official set of functionality supported in IIS 7 vs IIS 6? Should we completely avoid running it on IIS6?
You do not loose any functionality of ASP.Net MVC; however, you have one of two options. You can either define an extension on your URL's which will allow you to set up mapping. So for example:
www.example.com/books/computer/list
might become:
www.example.com/books.mvc/computer/list
You can use any extension you want so long as you map to ASP.Net. I am currently using .aspx which meant I could avoid changing IIS configuration at the sacrifice of having extensionless URLs.
The other option as mentioned is using a wild card mapping. What this does is route all requests to ASP.Net. Even requests for static content such as images. This does have a negative effect on performance that you will want to measure. There are ways around this, I believe such as placing all your content in a specific virtual directory that you turn off the wild card mapping for, but I haven't fully explored that option.
I think the issue with IIS6 is extensionless URLs that you can easily achieve by adding a wildcard ISAPI map in IIS configuration.
So, no. While I love IIS7 integrated mode and strongly recommend using it, you won't lose functionality using it. I've deployed several ASP.NET MVC 1.0 projects on Windows Server 2003/IIS6.
Url rewriting can help you to solve the problem. I've implemented solution allowing to deploy MVC application at any IIS version even when virtual hosting is used.
http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx