I am absolutely frustrated by the Azure SDK for years now I have been using it and this problem of outputting errors to the log file still arises:
Application has thrown an uncaught exception and is terminated:
Error: ENOENT, no such file or directory 'C:\DWASFiles\Sites\pazooza\VirtualDirectory0\site\wwwroot\iisnode\RD00155D4313F9-20848-stdout-Tue Mar 26 2013 03:10:56 GMT+0000 (GMT Standard Time).txt'
at Object.openSync (fs.js:240:18)
at Object.writeFileSync (fs.js:628:15)
at SyncWriteStream.<anonymous> (D:\Program Files (x86)\iisnode\interceptor.js:181:20)
at Object.<anonymous> (console.js:25:18)
at IncomingMessage.<anonymous> (C:\DWASFiles\Sites\pazooza\VirtualDirectory0\site\wwwroot\utils\facebook.js:69:21)
at IncomingMessage.emit (events.js:88:20)
at HTTPParser.parserOnMessageComplete [as onMessageComplete] (http.js:130:23)
at CleartextStream.socketOnData [as ondata] (http.js:1288:20)
at CleartextStream._push (tls.js:375:27)
at SecurePair.cycle (tls.js:734:20)
As you see the error occurs because the fs object is trying to find something that is on the c: drive, what is the c: drive pointing to my local machine got to do with the logging system that is suppose to be in the Azure Websites?
And D:\Program Files (x86)\iisnode\interceptor.js
What is that all about shouldn't it be pointing to a resource in the Azure Cloud Websites Instance?
Can anyone from Azure SDK tell me how to make this error go away.
I asked this months and months ago and we thought we had it fixed by now its back again ... very frustrating Microsoft... wtf are you guys doing to make our lives easier?
My other questions on here that lead to this problem:
Webmatrix 2 broken and
Windows Azure Node.js Internal Server Error
My node.js web.config file looks like this:
<configuration>
<system.webServer>
<handlers>
<!-- indicates that the server.js file is a node.js application to be handled by the iisnode module -->
<add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
</handlers>
<rewrite>
<rules>
<!-- Don't interfere with requests for node-inspector debugging -->
<rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^server.js\/debug[\/]?" />
</rule>
<!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
<rule name="StaticContent">
<action type="Rewrite" url="public{{REQUEST_URI}}"/>
</rule>
<!-- All other URLs are mapped to the Node.js application entry point -->
<rule name="DynamicContent">
<conditions>
<add input="{{REQUEST_FILENAME}}" matchType="IsFile" negate="True"/>
</conditions>
<action type="Rewrite" url="server.js"/>
</rule>
</rules>
</rewrite>
<!-- You can control how Node is hosted within IIS using the following options -->
<iisnode
loggingEnabled="true"
devErrorsEnabled="true"
/>
</system.webServer>
</configuration>
Any help or advice as to why this error shows up when I set logginEnabled="true" would be appreciated.
When I set loggingEnabled to false no errors and the site runs fine, but when its turn on everything is effed up!
Could you file an issue under: https://github.com/windowsazure/iisnode ?
Sounds like this is an issue with IISNode logging ? We may be able to help you there with further details on the issue.
Andre
Related
As a starting point for an application, I'm trying to get a simple Hello World running on Node in Azure (on a Windows app service). While the goal will be to push from an Azure DevOps pipeline, for now I'm just deploying from VS Code following this guide.
The application runs locally as expected, and the deploy to Azure is successfully moving the expected files (to include node_modules, package.json, app.js, and the various other code files). But the application is somehow failing to run correctly on Azure.
Any request results in a 500 error, whether for the root URL or explicitly for /app.js. (I was testing the latter to see if it just returned the file, but it's a 500 error.) I've enabled as much logging as I can find in Azure, but no more helpful information has surfaced. Just records of HTTP requests with generic 500 responses.
Some research led me to suspect that I need a web.config to tell IIS to use the node application. Following some samples found online, I've ended up with this:
<?xml version="1.0" encoding="utf-8"?>
<!--
This configuration file is required if iisnode is used to run node processes behind
IIS or IIS Express. For more information, visit:
https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config
-->
<configuration>
<system.webServer>
<!-- Visit http://blogs.msdn.com/b/windowsazure/archive/2013/11/14/introduction-to-websockets-on-windows-azure-web-sites.aspx for more information on WebSocket support -->
<webSocket enabled="false" />
<handlers>
<!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
<add name="iisnode" path="app.js" verb="*" modules="iisnode"/>
</handlers>
<rewrite>
<rules>
<!-- Do not interfere with requests for node-inspector debugging -->
<rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^app.js\/debug[\/]?" />
</rule>
<!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>
</rule>
<!-- All other URLs are mapped to the node.js site entry point -->
<rule name="DynamicContent">
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
</conditions>
<action type="Rewrite" url="app.js"/>
</rule>
</rules>
</rewrite>
<!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin"/>
</hiddenSegments>
</requestFiltering>
</security>
<!-- Make sure error responses are left untouched -->
<httpErrors existingResponse="PassThrough" />
<!--
You can control how Node is hosted within IIS using the following options:
* watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
* node_env: will be propagated to node as NODE_ENV environment variable
* debuggingEnabled - controls whether the built-in debugger is enabled
See https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config for a full list of options
-->
<!--<iisnode watchedFiles="web.config;*.js"/>-->
</system.webServer>
</configuration>
Which makes sense to me. It tells IIS to use iisnode, the entry point file, URL mapping to use that entry point, etc. After re-deploy I'm still getting generic 500 responses.
I'm a bit out of ideas on where else to look or what else to try at this time. I suspect it should be straightforward to just build a Hello World app and deploy it and that I must just be missing something. But what?
we have a nodeJS webapp at Azure which works fine.
When streaming the server logs, any time I load a page, I get a bunch of 404 errors on all resources (images, css, etc..). Yet the page shows up properly.
Detailed errors show the following:
Requested URL https://[myappname]:80/settings.png
Physical Path D:\home\site\wwwroot\settings.png
Logon Method Anonymous
Logon User Anonymous
The requested URL is clearly wrong, it should be https://[myappname].azurewebsites.net/settings.png, which is the public URL for the given resources, and works fine.
This problem loads huge amounts of logs and makes it impossible to use Web Server logs for now.
thank you!
Edit: unlike this problem, my pages load properly and the resource files are well available.
Solved I have added the following handler to my web.config :
<add name="UrlRoutingModule-4.0" path="*" verb="*" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
I believe you need to configure a ruleset in your web.config for static file content.
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>
</rule>
Node.js applications running on Azure Web Apps are hosted on IIS via IISNode. So, a web.config file is required to config your application on IIS. If you deploy your app to Azure App Service via Continuous Deployment, the web.config file will be automatically generated by Azure. Or you can download the file from here.
I am posting default web.config just for your reference"
<?xml version="1.0" encoding="utf-8"?>
<!--
This configuration file is required if iisnode is used to run node processes behind
IIS or IIS Express. For more information, visit:
https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config
-->
<configuration>
<system.webServer>
<!-- Visit http://blogs.msdn.com/b/windowsazure/archive/2013/11/14/introduction-to-websockets-on-windows-azure-web-sites.aspx for more information on WebSocket support -->
<webSocket enabled="false" />
<handlers>
<!-- Indicates that the app.js file is a node.js site to be handled by the iisnode module -->
<add name="iisnode" path="app.js" verb="*" modules="iisnode"/>
</handlers>
<rewrite>
<rules>
<!-- Do not interfere with requests for node-inspector debugging -->
<rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^app.js\/debug[\/]?" />
</rule>
<!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>
</rule>
<!-- All other URLs are mapped to the node.js site entry point -->
<rule name="DynamicContent">
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
</conditions>
<action type="Rewrite" url="app.js"/>
</rule>
</rules>
</rewrite>
<!-- bin directory has no special meaning in node.js and apps can be placed in it -->
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin"/>
</hiddenSegments>
</requestFiltering>
</security>
<!-- Make sure error responses are left untouched -->
<httpErrors existingResponse="PassThrough" />
<!--
You can control how Node is hosted within IIS using the following options:
* watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
* node_env: will be propagated to node as NODE_ENV environment variable
* debuggingEnabled - controls whether the built-in debugger is enabled
To debug your node.js application:
* set the debuggingEnabled option to "true"
* enable web sockets from the portal at https://manage.windowsazure.com/#Workspaces/WebsiteExtension/Website/aarontestnode/configure
* browse to https://aarontestnode.azurewebsites.net/app.js/debug/
See https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config for a full list of options
-->
<iisnode watchedFiles="web.config;*.js" debuggingEnabled="false" />
</system.webServer>
</configuration>
Hope it helps.
thanks for your answer.
I have nearly the same web.config, automatically generated. There is just a slight difference in the rule you pointed :
<rule name="StaticContent">
<action type="Rewrite" url="public{PATH_INFO}"/>
</rule>
My server code includes this:
app.use(express.static(path.join(__dirname, 'public')));
I am trying to make corsanywhere work on Azure, and actually it works if I request something like this:
https://myserver.azurewebsites.net/www.remoteserver.com/query=john
But if I call this, I get a 500 error and I don't know how to track it (no error is produced in the logs in this case):
https://myserver.azurewebsites.net/http://www.remoteserver.com/query=john
This kind of request works well on the corsanywhere demo site or when I run my node app on my dev machine.
Update:
Node on Azure needs a web.config file. Here is mine:
<configuration>
<system.webServer>
<handlers>
<add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
</handlers>
<rewrite>
<rules>
<rule name="DynamicContent">
<match url="/*" />
<action type="Rewrite" url="server.js"/>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
I am wondering if this could be the culprit...
Thanks for your help
In Azure App Service (Windows OS), the characters :/ are not allowed in the URL path. This was discussed on SO before: Azure websites throw 500 error when there is a colon in the URL.
You could try a solution in #TimBunting's answer, or host your application on a Linux App Service instead.
I have a node app that has both a react native front end and a node API
I want to be able to just run npm install for both folders and then just have it run the start command "node server" (node/server/index.js) to have the node app running.
But I can't seem to figure out the release tasks to make this happen.
I am using the preview continous delivery that connects to visual studio online
In my opinion, it has nothing to do with continuous delivery. Since Azure App Service runs on Microsoft IIS, you'll need to have an IIS configuration file named web.config and should include the following section to match your requirement:
<handlers>
<add name="iisnode" path="./node/server/index.js" verb="*" modules="iisnode"/>
</handlers>
This indicates that the node/server/index.js file is a node.js site to be handled by the iisnode module.
<rewrite>
<rules>
<!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>
</rule>
<!-- All other URLs are mapped to the node.js site entry point -->
<rule name="DynamicContent">
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
</conditions>
<action type="Rewrite" url="./node/server/index.js"/>
</rule>
</rules>
</rewrite>
These rewrite rules determine where your static content and dynamic content should be located in.
For a completed web.config file you can check this post out.
The new version of Express separates the modules from the "server" file. It now lives in /bin/www and I'd prefer to keep this convention if possible.
In the package.json file, the "start" script clearly points to the right place, but this is seemingly ignored by Azure.
How do I deploy an Express 4.x app without having a server.js file in the root directory? All I need to do is make it automatically call node ./bin/www instead of node server.js. Is there another root configuration file I can add specific to the cloud host (Azure?) This is how I got this working in Heroku, etc.
updated answer
The Azure team has since fixed this internally. A newly deployed express 4 app should work just fine on Azure Websites without any additional changes.
original answer
I'll start with the tl;dr. Create a web.config file in the root of your application and use this xml.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<!--
By default IIS will block requests going to the bin directory for security reasons.
We need to disable this since that's where Express has put the application entry point.
-->
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
</hiddenSegments>
</requestFiltering>
</security>
<handlers>
<!-- Indicates that the www file is a node.js entry point -->
<add name="iisnode" path="/bin/www" verb="*" modules="iisnode"/>
</handlers>
<rewrite>
<rules>
<rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^bin\/www\/debug[\/]?" />
</rule>
<!--
First we consider whether the incoming URL matches a physical file in the /public folder.
This means IIS will handle your static resources, and you don't have to use express.static
-->
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>
</rule>
<!-- All other URLs are mapped to the node.js entry point -->
<rule name="DynamicContent">
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
</conditions>
<action type="Rewrite" url="/bin/www"/>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
This is a bit of a mess and took a while to track down. I really wish it was smart enough to look at package.json, but this is what we have to deal with for now. Normally Azure determine if it is a Node application by checking for an app.js or server.js file. If it finds that file, it will automatically create a web.config file very similar to what is above. In this case, it will detect app.js, but unlike 99% of other node applications, that's not actually the entry point. What we have to do is change the entry point to /bin/www like shown above.
The other issue we run into is that by default IIS blocks requests to the bin folder for security reasons. We can either rename the express bin folder, or tell IIS to get over it. That's what the hiddenSegments part of the xml file is for.