035.2 Lesson 1

To demonstrate Express’s basic features for receiving and handling requests, let’s simulate an application that requests some information from the server. In particular, the example server:

The first step is to create the JavaScript file that will operate as the server. Using npm, create a directory called myserver with the JavaScript file:

For the entry point, any filename can be used. Here we will use the default filename: index.js. The following listing shows a basic index.js file that will be used as the entry point for our server:

Some important constants for the server configuration are defined in the first lines of the script. The first two, express and app, correspond to the included express module and an instance of this module that runs our application. We will add the actions to be performed by the server to the app object.

The other two constants, host and port, define the host and communication port associated to the server.

If you have a publicly accessible host, use its name instead of myserver as the value of host. If you don’t provide the host name, Express will default to localhost, the computer where the application runs. In that case, no outside clients will be able to reach the program, which may be fine for testing but offers little value in production.

The port needs to be provided, or the server will not start.

This script attaches only two procedures to the app object: the app.get() action that answers requests made by clients through HTTP GET, and the app.listen() call, which is required to activate the server and assigns it a host and port.

To start the server, just run the node command, providing the script name as an argument:

As soon as the message Server ready at http://myserver:8080 appears, the server is ready to receive requests from an HTTP client. Requests can be made from a browser on the same computer where the server is running, or from another machine that can access the server.

All transaction details we’ll see here are shown in the browser if you open a window for the developer console. Alternatively, the curl command can be used for HTTP communication and allows you to inspect connection details more easily. If you are not familiar with the shell command line, you can create an HTML form to submit requests to a server.

The following example shows how to use the curl command on the command line to make an HTTP request to the newly deployed server:

The -v option of the curl command displays all the request and response headers, as well as other debugging information. The lines starting with > indicate the request headers sent by the client and the lines starting with < indicate the response headers sent by the server. Lines starting with * are information generated by curl itself. The content of the response is displayed only at the end, which in this case is the line Request received.

The service’s URL, which in this case contains the server’s hostname and port (http://myserver:8080), were given as arguments to the curl command. Because no directory or filename is given, these default to the root directory /. The slash turns up as the request file in the > GET / HTTP/1.1 line, which is followed in the output by the hostname and port.

In addition to displaying HTTP connection headers, the curl command assists application development by allowing you to send data to the server using different HTTP methods and in different formats. This flexibility makes it easier to debug any problems and implement new features on the server.

The requests the client can make to the server depend on what routes have been defined in the index.js file. A route specifies an HTTP method and defines a path (more precisely, a URI) that can be requested by the client.

So far, the server has only one route configured:

Even though it is a very simple route, simply returning a plain text message to the client, it is enough to identify the most important components that are used to structure most routes:

As we’ve seen in previous examples, the res parameter is responsible for returning a response to the client. Furthermore, the res object can change other aspects of the response. You may have noticed that, although the responses we’ve implemented so far are just brief plain text messages, the Content-Type header of the responses is using text/html; charset=utf-8. Although this does not prevent the plain text response from being accepted, it will be more correct if we redefine this field in the response header to text/plain with the setting res.type('text/plain').

Other types of response adjustments involve using cookies, which allow the server to identify a client that has previously made a request. Cookies are important for advanced features, such as creating private sessions that associate requests to a specific user, but here we’ll just look at a simple example of how to use a cookie to identify a client that has previously accessed the server.

Given the modularized design of Express, cookie management must be installed with the npm command before being used in the script:

After installation, cookie management must be included in the server script. The following definition should be included near the beginning of the file:

To illustrate the use of cookies, let’s modify the route’s handler function with the / root path that already exists in the script. The req object has a req.cookies property, where cookies sent in the request header are kept. The res object, on the other hand, has a res.cookie() method that creates a new cookie to be sent to the client. The handler function in the following example checks whether a cookie with the name known exists in the request. If such a cookie does not exist, the server assumes that this is a first-time visitor and sends it a cookie with that name through the res.cookie('known', '1') call. We arbitrarily assign the value 1 to the cookie because it is supposed to have some content, but the server doesn’t consult that value. This application just assumes that the simple presence of the cookie indicates that the client has already requested this route before:

By default, curl does not use cookies in transactions. But it has options to store (-c cookies.txt) and send stored cookies (-b cookies.txt):

Because this command was the first access since cookies were implemented on the server, the client did not have any cookies to include in the request. As expected, the server did not identify the cookie in the request and therefore included the cookie in the response headers, as indicated in the Set-Cookie: known=1; Path=/ line of the output. Since we have enabled cookies in curl, a new request will include the cookie known=1 in the request headers, allowing the server to identify the cookie’s presence:

The developer should be aware of potential vulnerabilities when using cookies to identify clients making requests. Attackers can use techniques such as cross-site scripting (XSS) and cross-site request forgery (CSRF) to steal cookies from a client and thereby impersonate them when making a request to the server. Generally speaking, these types of attacks use non-validated comment fields or meticulously constructed URLs to insert malicious JavaScript code into the page. When executed by an authentic client, this code can copy valid cookies and store them or forward them to another destination.

Therefore, especially in professional applications, it is important to install and use more specialized Express features, known as middleware. The express-session or cookie-session module provide more complete and secure control over session and cookie management. These components enable extra controls to prevent cookies from being diverted from their original issuer.