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
Related
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
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.
I have custom errors turned on and when I go to
www.mywebsite.com/video/default.aspx it shows error which corresponds to 404 and this is fine
but when I go to www.mywebsite.com/video/ it shows a generic iis 404 error.
My other pages that have files work fine like
www.mywebsite.com/photo/ would redirect to www.mywebsite.com/photo/default.aspx because files exists and default is setup in IIS.
Please help. Thanks!
The 404 handler specified in the web.config only works for files handled by the ASP.NET runtime. This is why it is working for www.mywebsite.com/video/default.aspx and not www.mywebsite.com/video/, the generic error your observing is the one configured by default in IIS. You will need to go into IIS Manager and set 404's to be redirected to your PageNotFound.aspx.
Here's some more infomtion on configuring custom error messages in IIS 6.0.
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.