Home > Experiential Learning > Experiential Learning of Networking Technologies

Experiential Learning of Networking Technologies

Understanding Basic Errors

Let us look at some other most common errors seen by a user when accessing the web. These pertain to the cases when the URL specifies a a) non-existent web resource (error code 404), b) forbidden or inaccessible content (error code 403), or c) invalid request parameters such as improper request headers, non-understandable requests (error code 400).

When a client makes a request for a non-existent web resource, the web server does not find the resource in its repository of contents and thus responds with a status code of 404 (Not Found). From the browser, for example, type the URL http://myweb.com/unknown.html and the browser will indicate that the content is “Not Found”. The HTTP response line will contain the status value 404, and the description will also be “Not Found”.

Occasionally, when user accesses a web resource, the web server responds with a web page that says “Forbidden”. This error occurs when the web resource does exist, but the web server does not have the necessary permission to read the content of the requested resource. A simple case on Ubuntu occurs when the web server, running with the user id ‘www-data’, does not have read permissions for a static resource. To demonstrate this, create a file classified.html in the web server DocumentRoot and remove the read permission for this file (e.g., using the command ‘chmod 500 /var/www/html/classified.html’) using an account that is not www-data. A listing of files in the directory /var/www/html would look as follows (Table 4):

Table 4: List of files in DocumentRoot

When the client browser tries to access http://myweb.com/classified.html, the web server is blocked from reading the contents of the file, and will therefore generate a Forbidden response with status code 403. The status code and corresponding headers can be verified from the Network tab of the web console. To fix this error, ensure that the file classified.html has read permissions for www-data. Reloading the URL will now result in a response with status 200, and the contents of classified.html will be visible. A more realistic scenario where this occurs is when the response comes from a web application (e.g., a business logic application written in Python, Perl, PHP, C/C++, Java, etc.) which determines that the requesting user is not authorized to access the resource.

Occasionally, when using a client application where web requests are made directly by the application and not by the browser itself (e.g., by an java applet or an Active-X component), there is a possibility that the generated request does not follow the syntax and semantics of the HTTP protocol precisely, thereby inadvertently creating an erroneous request. When such a request is received by the web server, it does not understand the request fully and therefore responds with an error with status 400 (Bad Request).

Generating such requests from within the browser is difficult, because browsers are designed to always send properly formatted request. To experience such an error, we need to use more basic tools to generate erroneous requests. For this experiment, we will use the telnet command line tool, which is available by default on any Linux distribution (and Windows and Mac as well). From the command line terminal, type the command telnet myweb.com 80 followed by a header line Host myweb.com (Table 5). This header has a deliberate syntax error (the colon between Host and myweb.com is missing). The web server encounters this error while parsing the request header, and thus responds with the error status 400 Bad Request as shown in Table 6.

Table 5: Invalid HTTP request header

Table 6: Web server response with status 400

To resolve such an error, the user needs to ensure that all the request headers and parameters follow the proper syntax.In this example, when user addsthe missing colon (:) between the header name and value, the web server responds back with the proper response and status (200).

Summary

We have described an experimental setup where students configure an Apache webserver to study basic working of the HTTP protocol and experience both successful and erroneous responses that users encounter in real scenarios.

We have also provided insights into how to fix such errors. We believe that this hands-on experience improves the quality of student understanding of the underlying concepts. In the next article, we will discuss how to make use of the most commonly used headers that deal with caching, which helps students design efficient web applications. This also helps students debug such applications more effectively, reducing the time for application development.

References

[1] ACM/IEEE Computer Society, “Computer Science Curricula 2013: Curriculum Guidelines for Undergraduate Degree Programs in Computer Science”, Joint Task Force on Computing Curricula, Association for Computing Machinery (ACM) and IEEE Computer Society, ACM, New York, NY, 2013.
[2] Kurose, Ross, “Computer Networks: A Top Down Approach” 7th edition, Pearson Education Inc, 2016.
[3] Peterson, Davie, “Computer Networks: A Systems Approach” 5th edition, Morgan Kaufmann, 2012
[4] Forouzan, “Data Communications and Networking”, 4th edition, The McGraw-Hill, 2011.
[5] RFC 2616, “Hyper Text Transfer Protocol – HTTP/1.1”, Network Working Group, Request for Comments 2616. Fielding, Gettys et al. June 1999
[6] RFC 791, “Internet Protocol (IP), DARPA Internet Program Protocol Specifications, Request for Comments 791. ISI, Univ of Southern California, September 1981.
[7] Apache Web Server https://httpd.apache.org/docs/2.4

Pages ( 3 of 3 ): « Previous12 3

Leave a Comment:

Your email address will not be published. Required fields are marked *