Azure Web Site starting my Hapi Node.js site with socket protocol

Question

Whenever I deploy my Hapi.js web application to azure, it starts the server using the socket protocol (see output below).

socket:\\.\pipe\b5c0af85-9393-4dcb-bd9a-3ba9b41ed6fb
  GET              /                              
  GET              /{param*}                      
  GET              /api/employees                 
  POST             /api/employees                 
  GET              /api/employees/{id}            
  PUT              /api/employees/{id}            
  DELETE           /api/employees/{id}            
  POST             /api/worklog                   
  GET              /login                         
  POST             /login                         
Hapi server started @ socket:\\.\pipe\b5c0af85-9393-4dcb-bd9a-3ba9b41ed6fb
150914/214730.270, [response], socket:\\.\pipe\b5c0af85-9393-4dcb-bd9a-3ba9b41ed6fb: [1;32mget[0m / {} [32m200[0m (316ms) 

However, whenever I am running this locally, it starts using http... I have not run into this issue using express or loopback, only Hapi. Is there some sort of configuration that I am missing? This is the server.connection function:

var server = new Hapi.Server();
var host = process.env.host || '0.0.0.0';
var port = process.env.port || 3000;

server.connection({host: host, port: port});

The reason this is a big deal is because I cannot pass socket://*<mydoamin>* to google as a callback URI for OAuth.

Answer 1

You shouldn't need to pass socket://<domain> to google, you'd pass the normal https://yourDomain.com or even the https://yourSiteName.azurewebsites.net to Google for OAuth callback and it should work as you would expect.

The fact that the node application is listening on a pipe rather than a normal tcp socket is just an implementation detail of iisnode. Basically the problem is that node has it's own webserver so you can't use it with other webservers like IIS, Apache, nginx, etc. iisnode bridges the gap between IIS and node in that it allows IIS to listen to the HTTP port on the machine 80 and when IIS gets a request on that port, it just forwards it to the node process that's listening on a named pipe. This allows you to manage your sites in IIS as you normally would on a Windows Server machine, while actually writing your app in node.

You can think of it as 2 webservers running on the box, one (IIS) is acting as a proxy for the other (node) where all the work is actually happening. The fact that the iisnode developer chose to use a named pipe instead of a normal tcp socket is odd (though kind of understandable since you can't easily reserve a port per se as you can a pipe), but it's the way it is.