I've got a website running under ASP .NET 2/IIS7/Vista. I have a URL rewriting module which allows me to have extensionless URLs. To get this to work I have configured the system.webServer section of the config file such that all requests are forwarded to the aspnet_isapi.dll. I have also added the URL rewrite module to the modules section and set runAllManagedModulesForAllRequests to true.
When I start up the website and visit one of the pages that uses the URL rewriting, the page is rendered correctly. However if I then visit another page the site stops working and I get a 404 not found. I also find that my breakpoint in the URL rewriting module is not getting hit. It's almost as if IIS forwards the first request to the rewriter, but subsequent ones go somewhere else - the error page mentions Notification as being MapRequestHandler and Handler as being StaticFile.
If I then make a small change to the web.config file and save it, triggering the website to restart, I can then reload the page in the browser and it all works. Then I click another link and it's broken again.
For the record, here's a couple of snippets from the config file. First, under system.web:
<httpModules>
<add name="UrlRewriteModule" type="Arcs.CoopFurniture.TelesalesWeb.UrlRewriteModule, Arcs.CoopFurniture.TelesalesWeb" />
</httpModules>
and then, under system.webServer:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriteModule" type="Arcs.CoopFurniture.TelesalesWeb.UrlRewriteModule, Arcs.CoopFurniture.TelesalesWeb" preCondition="managedHandler" />
</modules>
<handlers>
<add name="AspNet" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
</handlers>
<validation validateIntegratedModeConfiguration="false" />
</system.web>
The site is running under classic rather than integrated pipeline mode.
Does anyone out there have any ideas? I suspect my configuration is wrong somewhere but I can't seem to find where.
This is a bit of a long shot, but have you tried actually making the configuration changes inside of IIS?
I know that the web.config way is supposed to be 100% foolproof, but I've seen a few things where it helps to just configure it in IIS to get it working correctly.
You also may want to check out the new IIS7 rewrite module. you can read more about it here http://learn.iis.net/page.aspx/460/using-url-rewrite-module/, but chances are it will be more solid then your homegrown ISAPI filter
Try http://www.codeplex.com/urlrewriter it supports all the Apache mod_rewrite syntax and also supports Reverse Proxy.
If you're runnning in classic pipeline mode you don't need <system.webServer> section it is required for integrated mode
Enable wildcard script mapping
Open the IIS7 Manager and navigate to your site
Click on Handler Mappings
In the Action panel click on "Add Wild Card Script Map"
In the dialog point to aspnet_isapi.dll
Click Yes on the message box that asks you to confirm your mapping
In the action panel click on "View Ordered List" and move your WildcardScriptMap just before StaticFile Handler
This should bee enough.
I'm ashamed to admit this but it was a simple mistake by me :-(
In my URL rewriting module, the code to rewrite the request path was in the Init method, when it should have been inside an Application.BeginRequest handler. This explains why the rewriting worked only the first time the site was hit.
Sorry to have wasted your time people!
Related
I have an old asp.net (non-core, non-mvc) https webapp which has a number of IHttpHandlers which serve files using a setup in my web.config like so:
<system.webServer>
<handlers>
<add name="DocumentAttachmentHandler"
path="*/Secure/DocumentAttachment/*/*/*/*/*.*"
type="[company].[product].WebApp.AttachmentHandlers.DocumentAttachmentHandler, [company].[product].WebApp"
verb="GET"/>
I want to add a new handler that is localhost only (only accessible internally) and is http instead of https.
This is what I added:
<add name="MyFileHandler"
path="*/Public/My/*/*.*"
type="[company].[product].WebApp.AttachmentHandlers.MyAttachmentHandler, [company].[product].WebApp"
verb="GET" />
But my breakpoint in the handler doesn't hit when I call:
http://localhost:44300/[product]/Public/My/[fileId]/[filename].[ext]
...because my webapp is https. It does hit when I change my entire webapp to http, but I obviously can't leave it like that ;-)
I tried setting path="http://localhost:44300/[product]/Public/My/*/*.*" and adding allowPathInfo="true" ...but that didn't work.
All my web searches return telling me how to make something secure, when I want to make mine less secure (sort of).
Please can someone tell me how I should go about doing this?
I´m using Plesk and in Web scripting and statistics I have Microsoft ASP support in ON.
I uploaded a application (which works correctly in my PC) to a directory and it can be shown but when I go to the aspx file it shows me the 404 error (The path is the correct).
I noticed that some files in "shtml" extension are neither shown by the server.
This is my very first time with ASP.NET, ISS8 and Plesk. I don´t know what to do. I will thank you for your help
You have to set the HTTP Handler Extension. If you have no access to IIS directly, you could do on the web.config:
Open the Web.config file for the application, locate the httpHandlers element of the system.web section and add an entry for the file-name extension
Example:
<system.webServer>
<handlers>
<add name="SampleHandler" verb="*"
path="SampleHandler.new"
type="SampleHandler, SampleHandlerAssembly"
resourceType="Unspecified" />
</handlers>
</system.webServer>
For more configuration options please refer to:
https://msdn.microsoft.com/en-us/library/bb515343.aspx
and
https://msdn.microsoft.com/en-us/library/46c5ddfy(v=vs.100).aspx
Check also the Custom Handler Policy of Plesk that should not be enabled:
https://docs.plesk.com/en-US/onyx/administrator-guide/plesk-administration/securing-plesk/custom-handlers-policy.76787/
Here I've found also another interesting document:
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/handlers/
Scroll down and you'll find a piece of code to add the handlers programmatically, even if I suggest you to add them in your web.config
IIS Express is producing 403.14 Forbidden errors when a URL that would otherwise be handled through ASP.NET URL routing happens to correspond to a physical folder in my ASP.NET project. (The folder contains only code, and it's coincidental that the folder name happens to match the URL of a page; my URL structure is determined dynamically by a database, and users can edit that structure, so although I could just rename my project folder, in general I can't prevent this sort of collision occurring.)
This seems to be happening because the DirectoryListingModule steps in to handle the request, and then promptly fails it because directory browsing is disabled. I've tried removing this:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFile" path="*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
That removes the default StaticFile handler configuration, which has modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule", and replaces it with a configuration that provides just the feature I want. (I want static file serving, but I have no need for directory listing or default documents in this app.) But the effect seems to be that IIS then produces a completely empty (0 byte) response (with a 200 status) when I hit the offending page.
So next, I tried configuring the StaticFile handler to handle only the specific physical folders that I want to make available:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFileCss" path="style/*.css" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
<add name="StaticFileScripts" path="Scripts/*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
But when I hit the offending URL, this then produces a 404.4 - Not found error, with a message of The resource you are looking for does not have a handler associated with it.. (The Detailed Error Information on the error page says that we're in the IIS Web Core module, during the MapRequestHandler notification, the handler is Not yet determined, and there's an Error Code of 0x80070002, which is a COM HRESULT that corresponds to the Win32 ERROR_FILE_NOT_FOUND error.)
The mystifying thing is that it's not even bothering to ask ASP.NET whether it has a handler for it. IIS seems to be deciding all by itself that there definitely isn't a handler.
This only happens when there's a folder that matches the URL. All other resources with dynamically-determined URLs work just fine - IIS asks ASP.NET for a handler, ASP.NET's routing mechanism runs as normal, and if the URL corresponds to one of my dynamically defined pages, it all works fine. It's just the presence of a physical folder that stops this all from working.
I can see it's IIS doing this because I get one of the IIS-style error pages for this 404, and they have a distinctive design that's very different from the 404s produced by ASP.NET. (If I try to navigate to a URL that neither corresponds to a physical folder, nor to a dynamic resource, I get a 404 page generated by ASP.NET. So normally, IIS is definitely handing requests over to ASP.NET, but IIS is definitely getting in the way for these problematic resources.)
I tried adding this inside my <system.WebServer>, in case the problem was that IIS has decided that requests corresponding to physical folders do not meet the managedHandler precondition:
<modules runAllManagedModulesForAllRequests="true">
But that doesn't appear to help - it still doesn't get ASP.NET routing involved for URLs that correspond to physical folders. In any case, it would be suboptimal - I would prefer not to have managed handlers run for the content that I definitely want to handle as static content. I effectively want ASP.NET URL routing to be used as a backstop - I only want it to come into play if the URL definitely doesn't refer to static content.
I don't understand why ASP.NET isn't even asking ASP.NET what it thinks in this scenario. Why is it not calling into ASP.NET during the MapRequestHandler phase if there's a physical folder that happens to correspond to the URL?
When a physical file or folder with the same URL as the route is found, routes will not handle the request and the physical file will be served.
Althrough you can change this behavior by setting the RouteExistingFiles Property from the RouteCollection object to true.
Take a look at the MSDN page Scenarios when routing is not applied
I have created a simple HttpModule which removes whitespaces from response before sending it to the client. This works fine for an aspx page on IIS7.0 but if i create a static html page and call it, the HttpModule does not kick in (the way i know is because the source contains whitespaces, which otherwise should have been removed). Apparently there is something i m not doing right, but dont know what.
My website is in an Application Pool with .NET 4.0 and ManagedPipelineMode = Integrated.
I have added my module as a ManagedModule and refers to an strong-name-key assembly from GAC.
thanks
Edit- here is the system.webserver part from web.config
<system.webServer>
...
<modules runAllManagedModulesForAllRequests="true">
<add name="RemoveWhitespaceHttpModule"
type="HttpModules.Modules.RemoveWhitespaceHttpModule, HttpModules,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=8a83u4bi47o9fo0d"
preCondition="" />
</modules>
<defaultDocument>
<files>
<add value="TestForm.aspx" />
</files>
</defaultDocument>
</system.webServer>
Edit- Fixed it. For anyone interested, this is how my module checks the response and then decides whether to proceed with whitespace removal or not
if (contentType.Equals("text/html")
&& httpContext.Response.StatusCode == 200
&& httpContext.CurrentHandler != null)
{ ... }
The problem was with the third condition above httpContext.CurrentHandler != null. when calling this module for static .html pages, the currentHandler was null and hence the code never went inside to manipulate html. i have removed this third condition and it works now. thanks for your answers everyone
This should do the trick, in the web.config:
<modules runAllManagedModulesForAllRequests="true"></modules>
This is a quick and easy solution, but can cause issues / performance issues.
You need to look at the Handler Mapping in your IIS.
How a handler works is that on IIS, the handler is registered and supposed to handle a particuler type of page. You can look at the "Handler Mappings" in the IIS [In the run command type inetmgr and hit enter. IIS Manager will pop up and look for Handler Mappings in the IIS section.]
Forgive me if this is basic. I've never made one before and can't seem to figure out why it's not working. I wrote a little handler to do some parsing on CSS files. I added this:
<system.web>
<httpHandlers>
<remove verb="*" path="*.css"/>
<add verb="*" path="*.css"
type="MyNameSpace.CssRelativePathHandler,CssRelativePathHandler" />
</httpHandlers>
</system.web>
Nothing ever happens. CSS files get parsed normally. No errors, nothing, the code never runs. What am I missing? Shouldn't this cause the handler to be used when *.css files are served? (I added the "remove" later, since I thought perhaps I needed to do that to override a built-in hander, again, no difference either way).
This is IIS 6. I added the IIS 7 code anyway (after searching for answers) but makes no difference.
<system.webServer>
<handlers>
<add name="CssHandler" verb="*" path="*.css"
type="MyNameSpace.CssRelativePathHandler,CssRelativePathHandler" />
</handlers>
</system.webServer>
You need to configure IIS6 to send requests for .css files to ASP.Net.
Had you been using IIS7, your <system.webServer> element would have done that for you, but IIS6 predates this.
For IIS 6 you need to have to tell it to send *.css files to ASP.NET.
Launch IIS Manager
Right-click on Default Web Site
Click on the Home Directory tab
Under Application Settings click on Configuration...
Add a new association for .css and map it to .NET executable:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
It sounds like you need to configure IIS to enable ASP.NET to execute the .css extension.
Phil Haack has a walkthrough on doing that (just replace .mvc with .css under the heading "Mapping .mvc to ASP.NET"):
http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Or you can set up a wildcard mapping in IIS 6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5c5ae5e0-f4f9-44b0-a743-f4c3a5ff68ec.mspx?mfr=true
I'd recommend going with the first method as doing the wildcard approach will send all requests to ASP.NET - so it has a more overhead.
PS: Further down Phil's post, he also lists "IIS6 Extension-less URL" and also covers the wildcard mapping method.