I'm facing a problem:
I do want to do URL rewriting with ASP.Net
It works perfectly using my local settings, but once on the server it doesn't work as expected.
Local
Request to /unavailable-file.aspx gets well in the Application_Error (Global.asax.cs) and then is being redirected to /404.aspx
Request to /unavailable-random-folder or any other file gets well in the Application_Error (Global.asax.cs) and then is being redirected to /404.aspx
Remote
Any request to a .aspx file WILL be catched in the Application_Error
Every other request (.jpg, folder, etc...) will NOT be catched at all and thrown into the default 404 page error
My problem:
Yesterday I was installing my new website to the server and I saw that Application_BeginRequest was not even fired AT ALL on my server, when it was every time (for every file or folder requested) in my local computer (with visual studio).
I had to create an HttpModule and now I am successfully getting the events firing... but not for non .aspx requests.
Everything seems to be bound on the URL : when it ends with .aspx it's correctly managed and when it's not, it's just not managed at all.
What should I do to catch every Application_BeginRequest even for non aspx page?
I have that in my web.config to try to force the 404 errors into my page:
<customErrors mode="On"
defaultRedirect="404.aspx">
<error statusCode="404" redirect="404.aspx"/>
</customErrors>
But as I said, as long as it's not a request ending with .aspx it's not being redirected and I get the default ASP.Net 404 error.
(My host is "reliablesite" if it can help, and I have the settings of the 404 errors pointing to my 404.aspx page inside the manager (shared hosting), it does not change anything)
I wish everything would work as in local mode.
If you have any tip on how to resolve that problem let me know.
In the development web server every request is handled by the aspx engine, as that's all there is. In the live server different file types are handled by different engines.
To make the live server use the aspx engine for every request you have to change the configuration in IIS for the web site.
Related: ASP.net web.config doesn't catch all 404's
The solution of this problem is given here when you have a shared environment:
Active the ASP.Net Integrated Pipeline in your shared environment settings (a thing that is available since IIS 7)
Add this to the web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="RedirectHttpModule" type="RedirectHttpModule" />
</modules>
</system.webServer>
Where RedirectHttpModule is a custom module handling Application_BeginRequest for example.
The "runAllManagedModulesForAllRequests" means that all managed modules will be invoked for all requests to web application.
Related
I have a controller where an action returns a 404 error on ASP.NET MVC. Working locally, I get the page with 404 error correctly. When I deploy it to azure, instead of the page, I only get a text-only page:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
I've tried all three values on on customErrors mode in web.config (mode = Off, On, RemoteOnly) and it doesn't seem to change anything at all.
Why is Azure behaving differently on 404 errors and how can I make it behave the same as local IIS?
Okay I've found out the problem. Apparently, it wasn't even hitting the ASP.NET's custom errors handler, and was being caught at server level.
I've played with web.config and added this:
<httpErrors errorMode="Detailed">
<remove statusCode="500"/>
</httpErrors>
It now passes my error to the ASP.NET's custom error handler correctly.
I have several web servers and the proxy based on IIS ARR to balance the load between the web servers.
If user goes to not existing page web server returns custom "notfound" page with 404 status code (works correct if I do not use proxy) Unfortunately it has been overridden by the ARR and I see IIS standard 404 screen instead of returned from web server (as on picture http://i.snag.gy/v1xvY.jpg).
Does anyone know how this the overriding can be avoided to allow users see the custom 404 page?
Thanks in advance
Add
<httpErrors existingResponse="PassThrough"/>
to your web.config file. It should look something like this:
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough"/>
</system.webServer>
</configuration>
If you're developing an ASP.NET application, put it in the application's web.config file, not the proxy's.
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 got an .ASHX handler I want to use to process an HTTP PUT to allow me to upload files to the web server--the .ASHX file actually uploaded data and sticks the file elsewhere, so it never actually touches the disk here.
I've set the web.config to allow it to handle HTTP PUT, but IIS won't pass the request to my code unless I set the ACLs on the .ASHX files themselves to be writable--Which is kinda silly, since we're not actually going to write to those files.
If I set the ACLs, it works fine, but I'd like to be able to process the file without having to set the ACLs at all (I'm sure there's an appropriate way to make IIS just pass the HTTP PUT to the .ASHX file without checking the permissions on the file itself.
This is on Win2008 R2 (actually, it's on Azure's 2008 R2, but should be the same), using .NET 4.0
401 - Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials that you supplied.
There are several roadblocks to getting PUT (and DELETE) working with ASP.NET. Since you mention Win2008 R2 (IIS 7.5) I would check to see if the errors you are seeing mention the WebDAV module or handler.
WebDAV is enabled by default as of IIS 7.5. It will interfere with HTTP PUT and DELETE verbs on ASP.NET handlers and modules. If you're implementing a RESTful service you likely don't even utilize this functionality. Disable it via your web.config.
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>
Some other solutions are mentioned in this forum post entitled HTTP Error 405 With ASP.Net MVC and HTTP PUT on IIS 7.5.
I'm having problems with handling URLS that do not exist...
In my development environment, I navigated to http://localhost:XXXX/FakeLocation and would catch the HttpException and handle it properly.
When I deployed to my production location, I'm getting a 404 error when I navigate to http://MyProductionURL/FakeLocation. How can I make the production location throw the HttpException so my code can handle it similar to how it works in my development environment?
ASP.NET will only handle file extensions it is registered in IIS to handle. So if the page was foo.aspx, then by default, ASP.NET returns the 404 page as set in the web.config. And by default 404 for foo.xyz will be handled by IIS because IIS handles anything that doesn't have a mapping.
This page shows how to set up wildcard mapping so that all requests, regardless to extension are handled by asp.net.
You probably need to configure IIS on the production location. The easiest thing you can probably do is
Go to the Control Panel, and under Administrative Tools open Internet Information Services (IIS).
Right-click on your web site to bring up the properties.
Go to the Custom Errors tab
Select to the 404 error and edit properties on it.
Change the Message Type to URL.
Set the URL to the page you want them redirected to.
you can do this in the custom errors node of the web.config
<configuration>
<system.web>
<customErrors defaultRedirect="GenericError.htm"
mode="RemoteOnly">
<error statusCode="500"
redirect="InternalError.htm"/>
</customErrors>
</system.web>
</configuration>
Msdn Reference
Looks like IIS handle this exception and does not pass error to ASP.NET.
Please check http://www.chat11.com/How_To_Setup_A_Custom_404_Error_Handler_In_.NET