Dotnetnuke hijacks IIS Default Documents? - iis

After upgrading an older site to Dotnetnuke 9.2, all URLs to default documents fail (non-dnn folders).
For example:
DnnSiteDomain.com/podcasts <-- Fails
DnnSiteDomain.com/podcasts/default.asp <-- Works
DnnSiteDomain.com/podcasts/default.aspx <-- Works
DnnSiteDomain.com/podcasts/default.html <-- Works
This worked fine for years, and now all of a sudden doesn't work anymore. DNN is intercepting the URL and sending it to 404 (instead of the default IIS file), is there a setting somewhere to fix this?

Related

ColdFusion 10 Update 11 404 handler not firing

I know CF 10 has a number of issues surrounding 404 handling. This seems to be different from the other reports. Details:
Win2k8 R2/64 and IIS7.5
Upgrading from identical config on separate server. Only difference is CF9 -> CF 10. All works fine on CF9. Adobe CF9 Lockdown implemented on original server, CF10 Lockdown implemented on this server.
missing template handler set in CF Admin as /404.cfm, which should translate to the Cfusion root (c:\ColdFusion10\cfusion\wwwroot).
IIS has been config'd to trace failed 404 requests
IIS 404 handling is default (originally executed a CF URL but removed to simplify debug).
Coldfusion webroot where missing template handler resides is default install location
IIS site root is entirely different: c:\Other\Place\SiteRoot\
A sitewide error handler is also set in CF Admin in the same ColdFusion webroot and works as expected.
404.cfm is very simple:
<cfheader
statuscode="404"
statustext="Not Found">
<h1>404</h1><p>Page not found</p>
<cfoutput>#now()#</cfoutput>
Inputting the bad url [domain]/foo.cfm should display the above template. Instead I get an IIS error screen. The CF missing template handler is ignored. The IIS failed request trace says the url is
http://[mydomain]:80/jakarta/isapi_redirect.dll
and a detail view shows at Step 1
RequestURL="http://[mydomain]:80/foo.cfm
I've seen plenty of issues surrounding CF10 and 404's, but never that the missing template handler assignment is completely ignored. In CF9 this will generate output as expected. Anyone seen anything like this?
EDIT:
I have also tried config'ing this to match a different CF9 server I have running: Added a CF mapping to the web root of the site. Then placed the missing template handler in the web site's root rather than the CF default web root, lastly in cfadmin pointed to the missing template handler in the web site's root using the mapped folder. Same problem. Works fine in CF9 and not at all using CF10.
EDIT2:
As Miguel F pointed out in the comments, you can shut off HTML error codes in CF Admin and this will let the Missing Template Handler fire... BUT you get a 200 header to go with it. Apparently cfheader statements are ignored as I have tried placing the cfheader at the beginning and end of the template... still yields a 200. Visually fine but insofar as SEO is concerned thats a disaster. Just looked and my CF9 servers do not require this setting to be unchecked for their handlers to work.
EDIT3
Dana Kowalski's solution displays detailed IIS errors to the public, so for a 404 on, say, a made-up extension (foo.xyz), the screen will show file paths. Default behavior is to NOT display detailed errors except when running templates locally, and display custom error pages to visitors. The CF error template should work fine with that setting.
POSSIBLE SOLUTION
I stepped back to ColdFusion 9 as part of debugging this problem, and may have discovered the solution while debugging a separate related issue.
In the IIS Manager, click on the site in question. Select the Error Pages option. Select the 'Edit Feature Settings' link on the right side. Check that the 'Detailed Errors' option is selected.
If you have either of the other two selected, there are times IIS 7.x will take over and not let ColdFusion handle it.

Joomla : whenever i change URL rewriting and enable htaccess get error

My site was working fine for the last couple of months and suddenly stopped working. and the issue was backend was working fine but the front end does not load at all.
then I contacted server providers they saying they have not done any changes to the server and asking me to contact Joomla support to see any in-depth errors. they even said they cant find any issues from the logs.
Then what I did was I reinstall VirtueMart (mind you this is an e-commerce site). then it started to work again from the front end. but I realize follow on pages aren't working. so what I did was I remove url re-writing and change the .htaccess code to txt.
so the issue I am having now is I can see index.php file in the URL. but whenever I try to change use url rewriting and enable .htaccess I get this error
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#domain.au and inform them of the time the error occurred, and anything you might have done that may have caused the error.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
anyone have any ideas?
Suddenly stopped working, without any change from your end ?
Try to step backward and recall anything you did before the issues.
The virtuemart re-installation should not have any relation with the SEF settings and the htaccess.
All these seem to be a combination of different issues.
Have you made any changes on the htaccess file ?
Go in Joomla Global configuration and disable SEF settings. Set URL rewriting to No. Then try to load pages in the front-end.
If you need SEF URLs, follow these instructions about how to enable this feature in Joomla:
http://docs.joomla.org/Enabling_Search_Engine_Friendly_(SEF)_URLs

ServiceStack Rockstars - why does it not redirect to folder/ with IIS Express?

I'm trying out ServiceStack, and have cloned the RazorRockstars sample from Github.
If I open in Visual Studio 2012 and start RazorRockstars.WebHost project, it all runs fine in VS development server.
If I then change the project to use IIS Express 8, the URLs in the dead/alive menus no longer work correctly.
It turns out that the link in the menu points to directory name without a slash: http://localhost:2000/stars/alive/vedder, and when executed, the server will send back a 302 and redirect to http://localhost:2000/stars/alive/vedder/ (note the trailing slash), and after that all is well.
In IIS Express however, this redirect doesn't happen, and the url in the browser remains without a slash, which in turn breaks the page.
The interesting part, however, is that the default.cshtml page will execute from the directory, but the included partial content.md will not. It looks as if SS is aware this was a folder and will look correctly for default.cshtml, but then somehow fails to look for content.md partial.
Is this a bug with SS implementation or expected behavior? Presumably it would make sense for ServiceStack itself to return a 301 in this situation.
I just had the same issue.
I had to download the URL rewrite module for IIS. And create a rewrite rule in the web.config file in the RazorRockstars.WebHost project.
See this link for more detailed explaination. http://www.tugberkugurlu.com/archive/remove-trailing-slash-from-the-urls-of-your-asp-net-web-site-with-iis-7-url-rewrite-module

IIS 404 Error even when file exists?

I have been working with IIS 7 for a while and it has worked fine until it just suddenly started throwing 404 errors for my multiple websites even though they actually exist. All of the configurations seems fine (path, default document) but not a single file, no matter the format or location will be loaded.
Another strange thing is that everything works when I try to access the websites via localhost or 127.0.0.1 but not through my external IP.
Does anyone know why this could happen and how I can fix it?
Edit:
It appears this 404 page is not the built in IIS error page. It is associated with nginx but I'm not sure where the file is located on my server or why my pages are being intercepted.
It turns at the server was hijacked by Morfeus F***ing Scanner, which I was not aware was even a thing until this happened. It's activity showed up in the server access logs. I basically had to reset the entire server. It was quite a chore.

RewritePath not working in IIS 7.5 integrated mode

I got an issue when using HttpContext.RewritePath in HttpModule for URL rewriting.
Environment: Windows Server 2008 R2, IIS 7.5 integrated mode, .Net 4.0
In my project, most URLs will be rewritten to the same aspx page(Handler.aspx). The aspx page will do different thing based on the URL.
Example:
"/en/abc/" will be written to Handler.aspx. [Page output: This is abc]
"/en/test/" will be written to Handler.aspx. [Page output: This is test]
"/en/test/a.html" will be written to Handler.aspx as well. [Page output: This is test]. As I only check the string "test" and ignore the sting "/a.html", the output is same as the URL "/en/test/". And a.html doesn't exist in wwwroot folder, the URL is a bad case for testing.
I got a issue, if 2 or more requests that contain htm/html extension come simultaneously
Example: "/en/test/a.htm" or "/en/test/a.html"
HttpContext.RewritePath will not work for any request after that. Handler.aspx won't be called any more, and the page output will always be 'This is test' no matter what URL entered. Http status code is 200 when the issue occurs. Also if visit the real aspx page(Handler.aspx), it will display the same content 'This is test' as well. It seems like a server-side cache. And this issue can be resolved by recycling app pool in IIS.
In following cases, the issue won't occur:
Visit these two requests with a delay, for example visit "/en/test/a.html" first and wait 3-5 seconds, then visit "en/test/a.html" again. Everything works fine.
Change IIS pipeline from integrated mode to classic mode. If visit "/en/test/a.html", a IIS 404 page will be displayed.
Use Server.Transfer instead of HttpContext.RewritePath, everything works fine.
The URL contains .php, .jsp, .xml won't cause the issue
I have to find the root cause of it. Any potential reason may cause this issue?

Resources