A vulnerability scanning service regularly tests our site for PCI scan compliance. It has just started trying to access URLs with abnormal formatting, such as:
http://www.mydomain.com/ShoppingCart.aspx//ErrorPage.aspx%3fid%3d2?
We have a Custom Error Page set which works for everything except this. Is there any way to force IIS to display it for this type of URL?
The Error: Runtime Error - An application error occurred on the server....
We're using:
ASP.NET 2.0 (Framework 3.5)
IIS 7.0 (Windows Server Web 2008)
I've tried to debug this, but I can't reproduce this on IIS 6.0.
There might be a more simple solution, but if you're on IIS7 you can use URL Rewrite to match those type of URLs and map them back to your error page.
The %3f part isn't being parsed by IIS 7 and so it can't find the page. If you look in your site logs you'll probably see some 404's.
You'll need to configure IIS 7 to point to your errorpage.aspx file as it's default 404 page.
Related
I'm having an odd issue.
IIS 7 throws a 404 when trying to access url 'www.MYURL.co.za/dc/Fred.Basset'
We're handling the Fred.Basset part in the global.asax, but IIS is not even letting the request through.
I've managed to get it down to the 'as' being the issue - ie 'www.MYURL.co.za/dc/as' throws the 404.
If I give the url an extension (e.g.www.MYURL.co.za/dc/as.txt) I don't get the IIS 404 and it reaches the global.asax
I have no filters on IIS and nothing I can see that would cause this.
I've tried a URL Rewrite, but that only works if 'as' is not in the link.
Classic mode and Integrated mode problem
if use mvc on iis 7
select Integrated mode for iis
The URL rewrite was the issue - IT added a command to block certain file extensions, but it was blocking all occurences of those strings instead of just extensions
When I start a web app by loading a page deep in the site, I consistently get a 404 error when using ASP.NET Friendly URLs.
I can reproduce this by:
Start web app by loading page in website root
Navigate to page such as /Manage/ViewEmployee/1
iisreset
Reload page /Manage/ViewEmployee/1
Step 4 will always result in a 404 error. I can reproduce this consistently in my test environment:
Windows 2008 R2
IIS 7.5
ASP.NET 4.5
Microsoft ASP.NET Friendly URLs 1.0.0
I cannot reproduce this issue, however, with IIS Express on Windows 7.
Are there any web.config settings that I can add to address this with IIS 7.5?
Were you able to load the page in the first place by entering the URL in the browser? I suspect the issue to be a problem with the URL and not with the IISRESET. Since you are using the latest version of IIS, there should be no problems with the settings too for handling friendly url's.
We are in the process of migrating an ASP Classic/ASP.NET application from IIS 6 to IIS 7.5. Most things run just fine in classic mode but we are having alot of problems with how errors are handled by IIS 7.5. We do our error reporting using a classic ASP page where we capture the error information here then redirect to a page to display the error. Based on our testing both Server.GetLastError and Request.ServerVariables("SCRIPT_NAME") when accessed from the logging page do not return the error details and source. Are there other ways we should retrieve the error information on IIS 7.5 or perform the logging?
In case this helps, using freb we have noticed that IIS appears to generate a completely new request then begins executing our error capturing.
Thanks in advance.
#smaclell: See http://dylanbeattie.blogspot.com/2008/12/fun-with-servergetlasterror-in-classic.html for a potential solution for you.
Here's the relevant paragraph from the article:
There was a very similar known bug in Vista which was supposedly fixed
in SP1, but it looks like the same fix isn't part of Windows 2008
Server yet. There is a workaround, though - if you set the site's
default error property (under IIS settings -> Error Pages -> Edit
Feature Settings...) to the custom page, IIS will invoke
this page whenever an error is not handled by an explicitly configured
status-code handler (so your 404, etc. handlers will still work) - but
for some reason, handling the error this way means
Server.GetLastError() still works properly.
I am building an asp.net web application which has been working on local and staging. however, when i deployed to live, there is a little weird issue occurred. below is the live environment details.
live environment:
Server 2003
IIS 6
when the request url is below, if page not found, it will redirect to page 404 configured in the IIS.
"http://www.xxxx.com/folder1/default.aspx"
however, when the request url is below (with a dot in the folder), it will show a IIS default 404 message which is "The system cannot find the file specified." which isn't what i configured in the IIS and it seems like it skips all the http handlers and modules. Therefore, my custom http handler stop working with this kind of url.
"http://www.xxxx.com/folder.1/default.aspx"
My guess it something to do with the IIS setting. i have have several research, there is no other issue like me.
appreciated if anyone can help. Thanks a lot.
Dion
One of the possible reason could be tool such as UrlScan - you need to explicitly configured it to allow dot(.)s in the url - this can be done by editing <Windows Folder>\system32\inetsrv\urlscan.ini and setting AllowDotInPath=1
I have setup in the script maps for a site in the IIS metabase a wildcard mapping to ASP.Net for a particular directory within the site.
I have a handler setup in the web.config which should be handling requests for said path and it should never return an actual 404.
I have this configuration in place for another site on the same server which is working perfectly.
For this particular site I am receiving a 404 response for all requests matching the path. I don't know if I have a problem with the script maps or the web.config or the handler itself.
How can I find out where the problem lays so that I can troubleshoot it better?
Is there a concrete way for me to ascertain if the 404 is being returned by ASP.Net or IIS itself?
I am using IIS 6 on Windows Server 2003 with .Net 3.5 SP1.
Inspecting the 404 response showed that it was not coming from IIS since IIS had a default 404 page and this was returning a 0 byte response.
The error was actually in the handler.