The template settings affect the behavior of LoDash, and due to Node’s module caching, this will affect the entire application. This will likely cause unexpected error, especially you are writing a module or a library, and the application that requires the module will also use LoDash but with a different template setting:
After deploying a Node.js app with custom runtime to Google App Engine, when uploading file larger than 1MB, the server returns HTTP 413 status code, meaning the server is refusing to process the request because the uploading entity size is too large.
I had the following setup:
The App Engine application is Google managed
The application is Node.js app with custom Dockerfile
The application Docker container runs node command directly on port 8080
After accessing the server (which changed from Google managed to user managed), and checked the Docker containers:
It looks like Nginx is running as the proxy to Node.js application. When uploading file that is larger than 1MB, the response is HTTP 413 error:
<title>413 Request Entity Too Large</title>
<h1>413 Request Entity Too Large</h1>
And the Nginx access log from the server:
$ tail /var/log/nginx/error.log
2015/06/2512:00:00 [error] 7#0: *101623 client intended to send too large body: 1696805 bytes
By default, Nginx limits uploading size or client_max_body_size to be 1MB. The default size is just too small. A short video upload could easily exceed the limit. So, how to accept file upload larger than 1MB via Google Managed VMs in App Engine? Is there a way to change the value through app.yamlcustom runtime configuration file? Or a custom Nginx Docker container can be deployed along with the application Docker container?
Hexo is a fast, simple and powerful blog framework. You write posts in Markdown (or other languages) and Hexo generates static files with a beautiful theme in seconds. - https://hexo.io/docs/
To generate static files, I need a Node.js development environment. But as I move around from different computers and operating systems, this becomes inconvenient. I need a cloud development environment where I can access it from any device.
So, I have decided to move my blog to Cloud9 IDE, a development environment in the cloud. And this is the first blog from the environment.
In the example section of SuperTest (v0.15.0), it mentions something about ephemeral port:
You may pass an http.Server, or a Function to request() - if the server is not already listening for connections then it is bound to an ephemeral port for you so there is no need to keep track of ports. - https://github.com/visionmedia/supertest#example
Let’s dissect this sentence. There are a few key concepts to grasp:
The request function will accept either a function or an http.Server object.
When does the server not listening for connections?
What is an ephemeral port?
Taking a peek at the index.js file in SuperTest source code, it is easy to see that it accepts both function and http.Server object, but prefer latter:
// See `index.js` in [SuperTest] source code.
if ('function' == typeof app) app = http.createServer(app);
Only when initiating an Express app, it returns a function, not an object. And follows up on lib/test.js, when SuperTest detects the created server is yet to bind to any port number, it will invoke app.listen(0), so called ephemeral port. In fact, it is just a random port.
When something is ephemeral, it last for a very short time. When allowing a server to accept connections, we usually do is setting the server to listen on a specific port:
What if setting this to 0 like above or omit this port number?