I am not sure if that's how it supposed to work, or I missed something.
On any changes I make, app stops, but seems like it never starts by its own. When I make a call to page it takes long time then errors and then when I repeat call it works fine.
So seems like to start it again I have to poke it with request?
Anyone is familiar with iisnode ?
You could try watchedFiles attribute on the iisnode element in your Web.config file. Using this, you can set IISNode to watch your config file(s) and whenever they change IISNode will recycle the site.
watchedFiles="*.js;*.hbs;web.config;routes\*;views\*;controllers\*;models\*"
https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config
Related
I'm a student working on a project to benefit other students, and I am currently facing a problem with reloading with any other url than the main path.
The webpage is written from scratch (more or less) in React with no backend, but I still hoped that it would work. I am using react-router to change sub-directories.
I have understood that there is a difference between server- and client-url's, and that this issue most likely is related to that. In the app's main directory "webpage.com" everything works fine untill the page is refreshed. If a sub-directory such as "webpage.com/link" is "called" directly, I recieve an error. You can go and try for yourself btw.
Does anyone know of a nice way to fix this? Do I need to implement something like Node.js to fix this? If so, how? I would prefer not to use a hot-fix such as redirecting all sub-directory calls (such as "/link" (an actual page) or "/kejrngo" (jibberish) ) to "/".
I've cloned your project locally and it seems you have a problem with the server. As you said yourself it seems that only open url for your page is http://ifistudenter.no where at the beginning all application is rendered. After you try to refresh the page you are looking for a path that isn't available on the server and that is the reason you get 404.
What seems to be a problem is React Router itself with Apache server:
Please look at this: https://www.malikbrowne.com/blog/using-react-router-with-apache hope it helps
So, IIS is pissing me off. It keeps on screwing with my error handling. I have a number of IHttpHandlers registered, and they're doing a good job. When I connect locally, I get the response I expect. But when I connect remotely, IIS's CustomErrorModule starts interfering. I've played with system.webServer/httpErrors and ssytem.web/customErrors to no avail. The only thing that works is system.webServer/modules/remove#name=CustomErrorModule, but that requires setting lockItem="false" for CustomErrorModule in the system's applicationHost.config file. Which is not a solution I like.
Is there some way to entirely disable CustomErrorModule without messing with any system files? I.e. without having admin privileges?
Aha! In <system.webServer>:
<httpErrors existingResponse="PassThrough" />
This does exactly what I want.
I have an IIS rewrite rule that I'm trying to use.
When I set the Action to ‘redirect’ its working fine. Likewise, if I select Custom response and set some arbitrary status code, I’m getting that back in the HTTP response, so I know the rule is matching for my URL. However, I need to rewrite this (to act as a reverse proxy) but as soon as I change the action to ‘Rewrite’ it doesn’t take effect.
I have installed the Application Request Routing Module and enabled the proxy under ‘Server proxy settings’ (as per this page http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing).
I’ve tried everything from restarting the site(s), the server, IIS, the W3p process and nothing takes effect. I've added the rule at a server level as required and confirmed in the ApplicationHost.config file that it is there and correct.
Any ideas what isn't causing this to fire?
I've seen a few similar posts here on SO, but none of them either have a solution or work for me in this instance.
EDIT: OK, so if I change the application pool from integrated to classic, the rule seems to fire (which is weird as the rule is at a server level!?!). However, My site requires integrated mode to function. Anyone know whats going on here?
I'm not sure what I'm missing here, so hopefully someone can help me out. I'm working on a project where we're using Node and in the Run/Edit configurations I've down the following:
Node interpreter: This is the path to the node.exe file
which I checked out from Subversion
Working directory: this is where the "app.js" file is, this is the
path that from the command line you type node app.js and it starts the server
JavaScript file: app.js This is the name of the file that actually creates the server
Now from the main nav bar when I do Run / Run my server the box at the bottom pops up and tells me that Express server is listening on port 3000. Cool.
I can navigate to localhost:3000/myPage.html and I can get to the page just fine.
I added as JSON file to the same directory on my hard drive that myPage.html is in, and I can navigate to that as well by localhost:3000/largeTestData.json.
So the server is up and running and serving file as it should. My problem is that in my Webstorm project, I want to make an AJAX request to that largeTestData file. I do so using jQuery like:
var data = $.get('localhost:3000/largeTestData.json');
data.done(function(data){
console.log('here is your data');
cnosole.log(data);
})
When I do that I get the error (in Chrome)
XMLHttpRequest cannot load localhost:3000/largeTestData.json. Cross origin requests are only supported for HTTP.
and so I look at the URL and I'm seeing:
http://localhost:63342/
Obviously Webstorm has started the server correctly, but when I view an HTML file, it's not using that server (which, of course is why I'm getting the CORS error.
There's some fundamental stuff here which I'm obviously not getting. I need my IDE to deploy to the Web server that it started up, but it's not doing that. Please, someone give me a once over on all the technologies that I'm missing out on here.
WebStrom didn't start your node.js server, but serves static pages by its own internal HTTP server which doesn't know anything about node.js and Express.
The main problem:
When you start your node.js server, it's serving JSON files on port 3000. If you open an HTML-page with the little menu in WebStorm (where you can choose the browser), WebStorm opens the browser with an URL pointing to its own internal webserver running on a different port (e.g. 63342). JavaScript security prohibits loading data from a different host/port Same-origin policy.
It's not WebStorm's fault and you need a solution for this problem in production or you can't go live.
General Solution:
Either you have to ensure that HTML pages and JSON data come from the same host+port, or you can circumnavigate with (a) setting server-side headers ('Access-Control-Allow-Origin: *') as #lena suggested, or (b) using JSONP. Below you find some thoughts using nginx as a reverse proxy so from browser's point of view all requests go to the same host+proxy. It's a very common solution, but as mentioned above, there are other options.
Primitive solution:
Don't use WebStorm to open your browser. Load the page from http://localhost:3000/ and change the URL of the REST resource to $.get('/largeTestData.json'). You'll miss some comfort from your IDE, but you can immediately see that your program is working.
Comfortable solution:
As #lena suggested, there is a way to configure your Express/node.js as a server known to WebStorm. I haven't tried it, but I suppose you can then just press the Run-button and maybe the node.js plugin in WebStorm is as intelligent to know the static-maps in Express and know how to map an HTML-file to a web application URL and open the page in the browser with the URL served by your node.js application. (I'd be surprised once again if this really works magically, but maybe you can configure a mapping from files to URLs manually, I don't know.)
Dirty solution
With some options you can disable security checks, at least in Google Chrome. Then it's possible to load JSON data from a different port than your HTML page. I wouldn't recommend using these options (just my opinion).
Additional Hints
If you do more than just playing around with node.js and some UI fun and you have to serve your application "production-ready", then have a look at nginx to serve your static files and reverse proxy node.js requests from there. I'm using this setup even for development and it works like a charm.
Of course node.js / Express is able to serve static files as well, but IMO placing something like nginx in front of node.js (clustered) bring a bunch of advantages for production sites, e.g. load-balancing, ssl-offloading, avoid JSONP, in many cases performance, easier deployment updates, availability.
To get your code working, just change the URL in $.get() to full URL (including protocol):
var data = $.get('http://localhost:3000/phones.json');
In Webstorm 2016.3 (and probably earlier) there is now another option. Under the Configuration Settings for NodeJS runs, one can manually set the page and port to be loaded via Webstorm's "Browser/Live Edit" settings.
See the screenshot below for settings one can change.
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.