12. Node.js Lessons. Documentation of Http Module.
We will further refer to the http module quite often, so let us now explore its supporting materials, what we can find there and where.
Right now the http module combines two functional services. The first one is the server functionality. http.createServer creates a new object of a Server class. If a handler is transmitted, it will go to the request event. The second functional service is createClient.
This method is considered to be out of date, and we’ve got another one: http.request. The point is that it was built to create http-requests. Using this method Node.js can refer to another site or server. The http.Server is rarely used independently. An object gets created, and a handler gets hung up on a request event. Once the request has been received, the server will appoint a certain port and host using listen.
Next, when a request is received, the request event happens, and control is delivered to a handler function. It gets two arguments. The first one, request, is a request object, incoming data. The second one, Response, is a response object.
Let us start from the request object. Let me see, where we can find it in the supporting materials. Here we’ve got some abstracts difficult for understanding. Perhaps, they will be simplified in the future, when the module is re-written. ClientRequest is not a request object that we’re talking about. It is a request object, if we use http.сlient, which means we need to generate this request using Node.js. But if we do not use this functional service, ClientRequest has nothing to do with our case. We are rather interested in IncomingMessage. That is the very first parameter of the request handler function. It receives URL, method, headers and some other properties.
I would like to draw your attention to the fact that it contains only a few properties of a request object because IncomingMessage inherits to another class that is a so-called thread. We will talk about these threads a little bit later. That’s why event isn’t single, too. There are other events, and we’ll move to them later.
The server’s life cycle generally includes data enabling us to learn what exactly we’ve received. And then we respond by writing inside ServerResponse – the second parameter of the request handler. If you want to, you can add your own headers. It can be done through requesting writeHead, which immediately sends them as a response, or through another implicit way. The “implicit” here means they won’t be sent immediately, but will wait for the next command. In most cases you will need no special headers. You can write your response at the same moment: if it is a web page, you can write your respond using response.end and insert the page content as the first parameter. Also you can use the response.write method. Unlike response.end, it does not end the connection. That is why response.write is used in those cases, when we want to write something in response for several times: for example, if new data appear. In this case, we use end to end our response. The connection will be present, until end is requested or a client ends it or any error occurs.
An object answer has other event properties, which haven’t been mentioned above for the reason this article is devoted to ServerResponse. And it is a descendant of another class, which we will learn later. Right now we know enough to receive a request and send a general response to a browser
The lesson materials were borrowed from the following screencast.
We are looking forward to meeting you on our website soshace.com