As soon as I disable development mode, none of the RPC services are available any more.
Only the DefaultFrontend service with a Route to match of / returns the initial application page.
Any call to a Route to match other than / returns the usual 404 page with "Page not found. The requested URL could not be matched by routing. No Exception available"
When I enable development mode, my application works without errors and routing functions properly.
Any help with this problem would be much appreciated.
I deleted the files in /data/cache after disabling development mode.
There were only two: module-config-cache.application.config.cache.php and module-classmap-cache.application.module.cache.php.
Apigility re-created them with updated versions and now routing functions properly in production mode.
Should Apigility not delete those files automatically when disabling / enabling development mode?
Related
I have a web app that used to run on IIS at http://localhost:3878/Admin; however now for some reason I get this error when I try to access it in a browser:
This site can’t be reached
The connection was reset.
Try:
Checking the connection
Checking the proxy and the firewall
Running Windows Network Diagnostics
ERR_CONNECTION_RESET
Why would I be getting this error all of a sudden when the app worked earlier today? I checked in IIS to make sure the app is started. The IIS logs are not showing any requests to this app. Event Viewer shows a compile error related to this app (I tried to access an include aspx page directly from the browser; I want to fix that issue with the web app where it's displaying the source code from the aspx pages that are used in #include statements) but that shouldn't take the app down once and for all should it?
If someone else face ERR_CONNECTION_RESET with http. Then you could try https first. If https binding fix the problem. It would help narrow down the root cause.
You may need to check whether require https has been enabled or mistake. In some case, enable https or HSTS in project will cause ERR_CONNECTION_RESET.
Of course, enable https would be considered as a workaround.
I'm creating my first FubuMVC application. I've got a physical folder Demo and a route that should handle the "/demo" url. For some reason, when I try to debug it in Visual Studio, it issues a permanent redirect to "/demo/", and then returns HTTP Error 404.20 - Not Found (No default document). When I route the same action to /demostuff, everything works just fine. I noticed that my application startup scripts are fired on the first request, but it's somehow not routed to Fubu's HttpHandler.
I'm using IIS Express.
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 developed an app on a dev machine using ASP.Net MVC and all is fine and it works. I have moved it to the Prod Server and when I type http://mydomain.com I get the error:
The incoming request does not match any route
If I then make a request to http://mydomain.com/pagename I then get a IIS 7 404 page.
It is hosted in a Full Trust Mode and Integrated Pipeline according to Softsys hosting who its hosted with.
I am currently accessing the site via a temporary DNS name eg/http://mydomain.com.serv7.temphostspace.com and my host believes this might be it.
From the support ticket this is what they say *"I believe, this is caused since you are access your website through temporary URL http://mdomain.com.serv7.temphostspace.com/ and relevant setting might be missing in your configuration."
Any ideas?
Thanks
Your host is probably barking up the wrong tree, unless the site isn't configured. I'd try and request a static file you know is there to be certain. As for the problem at hand, how are you wiring up the routes? Could something in production be failing before this and prevent this from happening?
Anyhow, first place I would start is by using the ASP.NET Routing Debugger to see what routes your app thinks it has.
Similar problem: ASP.NET MVC running IIS7 deployment problem
Resolution from there: http://haacked.com/archive/2008/11/03/bin-deploy-aspnetmvc.aspx
Turns out it was trust issues not configured right
Today we tried to put an ASP.NET application I helped to develop on yet another production machine. But this time we got a very weird error.
First of all, from all the ASP.NET pages, only Login.aspx was working. The rest just show a blank screen when they should have redirected to Login.aspx. The HTTP response is 200, but no content.
Even worse - when I try to enter the address of some inexistent ASPX page, I also get HTTP 200! Or, when I enter gibberish in some existing ASPX page code (which should have been accessible without login) I also get HTTP 200.
If I enter the name of some inexistent resource (like asdasd.jpg), I get the expected 404.
The redirect to login page is written manually in Global.asax. That's because the application has to use some alternate methods of authentication as well, so I can't just use Forms Authentication. I would suspect that Global.asax is failing, if not for the working Login page.
Noteworthy facts are also that this machine is both a Domain Controller and has SharePoint installed on it. Although the website in question is listed in SharePoint's exception list.
I would check the following:
Is the application within a virtual application or its own site and not just a virtual directory?
Does the application have it's own App Pool? If it does not then is the app pool shared by apps in a different .net version.
Is the .net version of the application the correct one? 1.1 or 2.0?
Do the files in the file system have the correct permissions to be accessed via IIS?
Have you performed an IIS Reset?
Create a stand alone test.aspx page within your folder that just displays the date/time and check it works.
Make this single test.aspx page perform an exception (eg. divide by zero) and see what the outcome is.
More information required.
What Op Sys?
What mode IIS running under?
What version of .Net?
What version of SharePoint?
(Why are you using your DC as a web host?)
Does it work on the other production machines you've deployed to?
If so what is different between this machine and the working ones?
Did you deploy the same way?
Are you sure your hitting the right machine?
Are you sure your hitting the right web site?
What ISAPI components are installed globally and for the web site?
Is .aspx mapped to the ASP.Net ISAPI filter?
Do you have any HTTP Modules or HTTP Handlers configured?
Can you change the global aspx to write out some messages so you can be sure the piece of code you interested in is reaching?
Anything coming up on the IIS log or the event logs?
Addition:
What version of .Net?
By the sounds of it the .jpg request is being dealt with by IIS directly which is why you get the 404, but the .aspx request is being dealt with by something else which except for you login page, is always returning 200.
Assuming .aspx is wired correctly to .Net the the order of processing is based on ISAPI filters (high to low then global before site), then the ASP.Net ISAPI Extension (sorry I said this was a filter earlier but it's actually an extension). Then we get into the ASP.Net pipeline based on your .Net configs, and calls the HTTP Application (which includes your global.asax code), any HTTP Modules followed finally by a HTTP Handler. Your ASP.Net web forms are just fancy HTTP Handlers.
However, the request can be responded to and terminated from any point.
Since your code works on other machines though, I'm tempted to point a finger at SharePoint if it isn't installed on the working machines. Is this SharePoint 2007? That is also an ASP.Net application (I don't think 2003 was).