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.
Related
So Im reading that:
If a file name extension has not been mapped to ASP.NET, ASP.NET will
not receive the request. This is important to understand for
applications that use ASP.NET authentication. For example, because
.htm files are typically not mapped to ASP.NET, ASP.NET will not
perform authentication or authorization checks on requests for .htm
files. Therefore, even if a file contains only static content, if you
want ASP.NET to check authentication, create the file using a file
name extension mapped to ASP.NET, such as .aspx.
which I understand given the obvious .htm <> ASP.net ISAPI mapping in the webserver but what about routes in a route table? I'm not mapping those in the web server so how does the web server know to forward those URLs to ASP.Net??
So there are at least two pieces to this question:
The first is if you are running in IIS in classic mode versus integrated mode. Classic mode will make things behave like IIS 6, where everything is an ISAPI filter, including ASP.NET itself. Integrated mode takes advantage of the fact that IIS 7 was rewritten from the ground-up and now uses modules instead.
Secondly, the short answer of why IIS knows how to forward a URL to ASP.NET is the Routing Module in the IIS 7+ pipeline; ISAPI filters are now part of the ISAPI Filters Module.
For a visual description of how the IIS 7+ pipeline works from a Routing/URL-Rewriting perspective, read IIS URL Rewriting and ASP.NET Routing
So the good news is if you are very much attached to the ISAPI filter approach you can use the classic mode of IIS.
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.
Say I have a website www.abc123.com. What would be the best way to determine when users attempt to access pages like www.abc123.com/section1 and www.abc123.com/otherStuff ?
I've done some research and found that Request.PathInfo works quite well when the user visits www.abc123.com/Default.aspx/section1 but it does not work without having the Default.aspx portion included in the URL.
Right now all I get are 404 errors when attempting this with the built in IIS server in VS2k8 and on a published website. I'm using ASP.Net 3.5 and IIS 6 if those things matter.
This works better in IIS7 since it routes all request through the ASP.NET pipeline (not just requests for ASP.NET resources).
In IIS6, I think your best bet would be to write an HTTPModule. I think IIS passes all requests (not just requests for ASP.NET resources) through the HTTPModule pipeline.
In IIS7, you can just use your applications Global.asax to hook into the Application_BeginRequest event.
I am running 3.5 on IIS 6 and there are a few things to do, but it can be done. A post already covers this, look at ASP.NET routing on IIS 6.
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).
In asp.net 3.5, I'm rewriting the url
http://www.abc.com/archive/1108/harpersdecember
to the following
http://www.abc.com/article.aspx?docId=78
I'm using this code to do it:
Context.RewritePath("/article.aspx?docId=78");
It works fine locally but when I upload to the remote web server, I get a 404 when trying to reference the above page. Any suggestions why it works locally but not remotely?
You may need to create a wildcard mapping in IIS on the remote server so that all requests are processed by ASP.Net. If you do not do this any URLs without .ASPX on the end will not run through your URL rewriting code.
There is a good explanation of this (and other reasons you might use it) on Scott Guthrie's blog.
Not "may" - you definitely need to create a wildcard mapping. Visual Studio uses the cassini web server which essentially passes all requests through .net. IIS only forwards specific mapped requests (by default .aspx, .asmx, etc..) to .net - rewriting a URL in asp.net requires adding a new mapping to get the request to asp.net in the first place
Sounds to me like the production server does not have a default aspx page, ie: default.aspx. If it did, it would reroute the request to your handler.
Easy way to verify this, would be to create a directory and place a default.aspx file in it and try to request it using only the dir name, ie: server.com/newdir/
If that gives you a 404, then you know it for sure.