I'm trying to setup my umbraco site so that it does not use the .aspx extension. I made the necessary changes to the config files, but when I added the wilcard application mapping in IIS the homepage now comes back with an object reference error (at System.Web.UI.Control.ResolveClientUrl) if I try to access it from at the root (i.e. http://site.com/). The error doesn't occur if I add the default.aspx or if I browse to /home (the root node). Is there something else I need to setup to get the root node to run at the root url?
This is actually a problem with asp.net rather than merely umbraco - I found the answer on a DotNetNuke forum. The ResolveClientUrl function cannot handle a '/' URL. This was fixed by installing the latest service pack for asp.net 2.0.
Related
I have a website that was building without any issue on multiple servers.
But, when I copy/move it on the same machine from one folder to another folder: I started getting the error
The Virtual Path Maps To Another Application Which Is Not Allowed.
What am I doing wrong?
The source of this problem is that when one copies an ASP.NET Web Site to a new folder -- the properties setting associated with the solution "Virtual Path" is set to the folder name and not the root. The solution is to change the Virtual Path setting from the folder name to "/".
This can be found by right click the project and opening the properties dialog: Solution->Properties->Virtual Path-> Change to "/"
This isn't why your error happened but it may be useful to someone researching the problem who ends up here.
If your web app is running as an application within another IIS site (set via the IIS administration tool) and is attempting to reach resources of the other site by means such as HttpResponse.Redirect, make sure the project isn't set to use a separate IIS in Visual Studio. If it is, it may be firing up inside a different IIS than the rest of the site.
Additional check: Missing global.asax also causes the same error.
If you are creating a new HttpContext and calling any external
service, it also causes the same error.
Key is you should not create new HttpContext, change the existing
context to your needs.
I would like to be able to hide the existence of folders in my DotNet 2.0 website which is being hosted via IIS 7.5 that contain files that must continue to be accessible. For example, I want a person's web browser to be able to retrieve the file domain.com/css/style.css (which is needed to render the page) but if the person tries to access the URLs domain.com/css/ or domain.com/css I want them to receive a 404 error. (not a 403 error)
By default IIS 7.5 will give a 403 error which would still allow an attacker to know about the existence of the folder. I realize that an attacker could easily discover the existence of the "css" folder by visiting the site in their browser and seeing that files are being pulled from the "css" folder. That said, this is a requirement of the project that I have to comply with.
In IIS6 I used to be able to set the hidden attribute for the folder which would give me the 404 behavior I wanted, but this is no longer the case in IIS7.5. (IIS 7.5 gives a 500 error if I try to do this) IIS 7.5 is another requirement of this project. Also, in IIS6 I want able to create a wildcard mapping that would cause all requests to route through DotNet which would then allow me to create a 404, but again, this does not appear to work on IIS7.5.
I have already tried creating handlers in the web.config ( node) which works on my staging system but not on my production system. Also, this method seems like overkill because I have to create a c# handler and have a handler entry in the web.config for each folder I want to hide. I'd like a simpler solution, but also, the solution just seems to not work on my production system.
Ideally, requests to the folder that do not include the trailing forward slash should NOT cause a 301 redirect but should also cause a 404.
You could always put a handler/ASPX page as the default page for directories, and have that handler return a 404 error code.
I have a problem with my asp.net 4.0 application. When I call it on the server, it works, but when I call it from outside the server, it gives me a 404 error.
The link I call the asp.net application from is the good one. Other asp.net 4.0 applications are working fine when called from outside the server. The other applications are in another folder though, but I do not see why it would work under a folder and not another one. There is no IP restrictions on the applications.
Anyone got that error int eh past?
Thanks
EDIT:
The app is configured as an asp.net 4.0 application. it is stored in a virtual directory.
This link works:
http://localhost/Phonebook/PhoneBook/default-defaut.aspx
this link does not : https://www.test.com/Phonebook/PhoneBook/default-defaut.aspx
A coworker and me found the answer. It's because the server I called on my url was supposed to have a rule redirecting the browser to the right url. So IIS7 on my test server was setted up right.
Theres several things to check.
That test.com is even going to your server. Put a file in the root directory 'test.txt' that IIS lists as the root folder for your site. ensure you can get to it.
Once you verify your root site folder WORKS for ex., www.test.com/test.txt then ensure you have a virtual directory /phonebook that contains a folder phonebook within it.
Seems overkill to be having to folders named phonebook. Try taking one of them out and pointing your web application to your
c:\whatever\phonebook\phonebook folder.
Make sure port 443 is bound to your app if you're using https, that could be your problem.
I copied my app and put it somewhere else. Then I changed IIS to look at the new place and ran it. Debugging it - it runs through my Controllers in the new location fine. But when it nips off to get the view it goes to the old location of my app?!?
Have you changed anything in your Routes? The Routing engine is what grabs your views when the controller requests them. Perhaps your issue is in your global.asax file? I'm afraid that's all I can offer, without more information.
I used .NET Reflector to work out how the route engine works. Turns out it kind of caches the route. It wouldn't listen to me until I restarted IIS, renamed the old directory so it didn't exist anymore and stopped my devenv.exe process. Then finally it was sorted
Ok, wierd problem I cant figure out. Hopefully someone where can. I have inherited a site that was developed with a very over-architected Content Management System. I am having problems now with the redirection functionality built into it.
This is on a dedicated Windows 2003 server running ASP.NET 3.5 sp 1. The redirects are stored in the database, and I have confirmed that the correct redirect is in place in the database. Finally, the file extension .html has been mapped in IIS to the ASP.NET ISAPI. And there is an HttpHandler created to redirect the .html requests. The default documents on the server, in order, are:
default.aspx
index.aspx
default.asp
index.asp
default.html
index.html
for this example, we have two redirects both pointing to the same content page. /example and /example.html
when requesting /example.html it correctly finds the appropriate redirect in the database and does its magic. Bueno. When requesting /example it gives a 404 page. Its not even the asp.net yellowish 404 generic error page. Its the standard vanilla IIS 404 response so it appears that asp.net is not intercepting these requests.
Let me know if any other information is requested and I will try to provide what I can. Thanks in advance for all the great recommendation I am sure will come from the community.
You should be able to map a wildcard extension to go through the ASP.Net ISAPI DLL is the solution.
Installing Wildcard Application Mappings (IIS 6.0) may also be useful.
Without rewriting the CMS, you can put a physical file in a new directory "/example". This will trigger ASP.NET to intercept the request, and hopefully load your page.
If you want to really hack it up you can change the IIS 404 page to be a .NET page in your application that can handle the original request and redirect to the page you really want.
Yes this is correct because /example is not pointing to any file, it is pointing to directory in the web server. Check that Default.aspx/ default.html or any other atleast one of them exists in your app.
If you are using ASP.Net MVC for REST then check your actions are properly written.