Problem: Server (Part 1)

This course’s philosophy on academic honesty is best stated as "be reasonable." The course recognizes that interactions with classmates and others can facilitate mastery of the course’s material. However, there remains a line between enlisting the help of another and submitting the work of another. This policy characterizes both sides of that line.

The essence of all work that you submit to this course must be your own. Collaboration on problems is not permitted (unless explicitly stated otherwise) except to the extent that you may ask classmates and others for help so long as that help does not reduce to another doing your work for you. Generally speaking, when asking for help, you may show your code or writing to others, but you may not view theirs, so long as you and they respect this policy’s other constraints. Collaboration on quizzes and tests is not permitted at all. Collaboration on the final project is permitted to the extent prescribed by its specification.

Below are rules of thumb that (inexhaustively) characterize acts that the course considers reasonable and not reasonable. If in doubt as to whether some act is reasonable, do not commit it until you solicit and receive approval in writing from your instructor. If a violation of this policy is suspected and confirmed, your instructor reserves the right to impose local sanctions on top of any disciplinary outcome that may include an unsatisfactory or failing grade for work submitted or for the course itself.

Your work on this problem set will be evaluated along four axes primarily.

To obtain a passing grade in this course, all students must ordinarily submit all assigned problems unless granted an exception in writing by the instructor.

First, join David for a tour of HTTP, the “protocol” via which web browsers and web servers communicate.

Next, consider reviewing some of these examples from Week 7, via which we introduced HTML, the language in which web pages are written.

And also some of these examples, via which we introduced CSS, the language with which web pages can be stylized.

Next, consider reviewing some of these examples, via which we introduced HTML forms, which we used to submit GET queries to Google.

For another perspective altogether, join Daven for a tour of HTML too. Don’t miss the bloopers at the end!

Finally, join Joseph (and Rob) for a closer look at CSS.

First, log into cs50.io and execute

within a terminal window to make sure your workspace is up-to-date.

Then execute

at your prompt to ensure that you’re inside of unit6 (which is inside of workspace which is inside of your home directory). Then execute

to download this problem’s distro. Unzip the ZIP file (remember how?) and then delete the ZIP file from your unit6 directory. Navigate into your newly-created server directory (remember how?) and type:

You should see that your directory contains five files and a folder.

Now execute

(which is a hierarchical, recursive variant of ls), and you should see that the directory contains the below.

Dang it, still C. But some other stuff too!

Go ahead and take a look at cat.html. Pretty simple, right? Looks like it has an img tag, the value of whose src attribute is cat.jpg.

Next, take a look at hello.html. Notice how it has a form that’s configured to submit via GET a text field called name to hello.php. Make sense? IIf not, try taking another look at the walkthrough for search-0.html.

Now take a look at hello.php. Notice how it’s mostly HTML but inside its body is a bit of PHP code:

The <?= notation just means “echo the following value here”. htmlspecialchars, meanwhile, is just an atrociously named function whose purpose in life is to ensure that special (even dangerous!) characters like < are properly “escaped” as HTML “entities”. See http://php.net/manual/en/function.htmlspecialchars.php for more details if curious. Anyhow $_GET is a “superglobal” variable inside of which are any HTTP parameters that were passed via GET to hello.php. More specifically, it’s an “associative array” (i.e., hash table) with keys and values. Per that HTML form in hello.html, one such key should be name! But more on all that in a bit.

Now the fun part. Open up parser.h and parser.c.

The challenge ahead is to implement the parsing part of a web server that knows how to serve static content (i.e., files ending in .html, .jpg, et al.) and dynamic content (i.e., files ending in .php).

Want to try out the staff’s solution before we dive into distribution code? Execute the below to download the latest version of the staff’s solution, as the version in CS50 IDE by default is outdated. Note that the O in -O is a capitalized letter O, not a zero.

Then execute the below to run the staff’s implementation of server.

You should see these instructions:

Looks a bit complex, but that’s just a conventional way of saying:

Let’s try it out. Execute the below within your own ~/workspace/chapterB directory so that the staff’s solution uses your own copy of public as its root.

You should see output like the below.

Toward the top-right corner of CS50 IDE, meanwhile, you should see your workspace’s “fully qualified domain name,” an address of the form ide50-username.cs50.io, where username is your own username. Visit https://ide50-username.cs50.io/ (where username is your own username) in another tab. You should see a “directory listing” (i.e. an unordered list) of everything that’s in public, yes? And if you click cat.jpg, you should see a happy cat. If not, do just reach out to classmates or staff for a hand!

Incidentally, even though server is running on port 8080, CS50-IDE’s is “port-forwarding” port 80 (which, recall, is browsers’ default) to 8080 for you. That’s why you don’t need to specify 8080 in the URL you just visited.

Anyhow, assuming you indeed saw a happy cat in that tab, you should also see

in your terminal window, which is the “request line” that your browser sent to the server (which is being outputted by server via printf for diagnostics’ sake). Below that you should see all of the headers that your browser sent to server followed by

which is the server’s response to the browser (which is also being outputted by server via printf for diagnostics’ sake).

Next, just like I did in that short on HTTP, open up Chrome’s developer tools, per the instructions at https://developer.chrome.com/devtools. Then, once open, click the tools’ Network tab, and then, while holding down Shift, reload the page.

Not only should you see Happy Cat again, you should also see the below in your terminal window.

You might also see the below.

What’s going on if so? Well, by convention, a lot of websites have in their root directory a favicon.ico file, which is just a tiny icon that’s meant to be displayed in a browser’s address bar or tab. If you do see those lines in your terminal window, that just means Chrome is guessing that your server, too , might have favicon.ico file, which it does!

Here’s a quick walkthrough if a demo may help.

Alright, now try visiting https://ide50-username.cs50.io/cat.html. (Note the .html instead of .jpg this time.) You should see Happy Cat again, possibly with a bit of margin around him (simply because of Chrome’s default CSS properties). If you look at the developer tools’ Network tab (possibly after reloading, if they weren’t still open), you should see that Chrome first requested cat.html followed by cat.jpg, since the latter, really, was specified as the value of the img element’s src attribute that we saw earlier in cat.html. To confirm as much, take a look at the developer tools’ Elements tab, wherein you’ll see a pretty-printed version of the HTML in cat.html. You can even change the HTML, but only Chrome’s in-memory copy thereof. To change the actual file, you’d need to do so in the usual way within CS50 IDE. Incidentally, you might find it interesting to tinker with the developer tools’ Styles tab, too. Even though this page doesn’t’ have any CSS of its own, you can see and change (temporarily) Chrome’s default CSS properties via that tab.

Okay, one last test. Try visiting https://ide50-username.cs50.io/hello.html. Go ahead and input your name into the form and then submit it, as by clicking the button or hitting Enter. You should find yourself at a URL like https://ide50-username.cs50.io/hello.php?name=Alice (albeit with your name, not Alice’s, unless your name is also Alice), where a personalized hello awaits! That’s what we mean by “dynamic” content. By submitting that form, you provided input (i.e., your name) to the server, which then generated output just for you. (That input was in the form of an “HTTP parameter” called name, the value of which was your name.) Indeed, if you look at the page’s source code (as via the developer tools’ Elements tab), you’ll see your name embedded within the HTML! By contrast, files like cat.jpg and cat.html (and even hello.html) are “static” content, since they’re not dynamically generated.

Neat, eh?? Though odds are you’ll find it easier to test your own code via a command line than with a browser. So let’s show you one other technique.

Open up a second terminal window and position it alongside your first. In the first terminal window, execute

from within your ~/workspace/unit6 directory, if the server isn’t already running. Then, in the second terminal window, execute the below. (Note the http:// this time instead of https://.)

If you haven’t used curl before, it’s a command-line program with which you can send HTTP requests (and more) to a server in order to see its responses. The -i flag tells curl to include responses’ HTTP headers in the output. Odds are, whilst debugging your server, you’ll find it more convenient (and revealing!) to see all of that via curl than by poking around Chrome’s developer tools.

Incidentally, take care not to request cat.jpg (or any binary file) via curl, else you’ll see quite a mess! (You’re about to try, aren’t you.)

Unfortunately, your server right now doesn’t have functionality… yet! If you open up parser.h, you’ll see declarations and descriptions for six functions, error, extract_request, extract_headers, parse, extract_query, and respond. While implementing your server, do take care to note the follow.

Alright, ready to go?

Recall that HTTP messages adhere to a “grammar,” which is to say they’re formatted according to a set of rules, patterns that web servers and web browsers can parse. Consider a (simplified) grammar below, wherein any bold symbol is further defined by some other rule. Know that CRLF represents \r\n, that SP represents a single white space, that * means “zero or more” (of whatever’s in parentheses), that / means “or” and that square brackets mean something’s optional.

One important task of web servers is to parse the HTTP message to ensure the messages are “grammatically correct”.

Before we jump into coding, let’s review a old friend from our past: pointers (you’ll thank us later)! Recall that a string is just a char*, which is a pointer to single character. The program will then continue reading 1 byte (the size of a char) at a time until a \0 is reached. So if we have the following string:

Then the char* pointer, word, would point to the first letter in the string, which in this case, is h. Let’s arbitrarily say that h is located in memory at location 0x05 (remember hex?). Then the e would be at 0x06, the l at 0x07 and so on and so forth until the NULL terminator is read at 0x11. So if we had a pointer that pointed to the NULL terminator, and the pointer, word, we can get the length of the string by subtracting the pointer, word, from the pointer that points to the NULL terminator (0x11 – 0x05 = 0x0C which is 12, the length of the string word). Remember, all strings end with a NULL terminator, even an empty string such as ””!

Still confused? Open up pointers.c and take a look at the code inside. Here, we parse a sentence, ”hello, world” to find the first and second words of the sentence. We isolate the variables, once in a char array and once using dynamically allocated memory. Note that strcpy copies in the ’\0’ whereas strncpy does not. You’re more than welcome, and in fact encouraged, to use pointers.c as a reference throughout this problem.

Feel free to divide the work in whichever manner you believe to be the most efficient, but our recommendation is for one person to take on the extract_request, extract_headers, and extract_query, while the other person tackles parse. Be sure to communicate throughout the whole coding and problem-solving process to make the problem much easier! After all, two heads are better than one.

If you try to run your version of server, you’ll see that it doesn’t do much at all. Now that we had that little review of pointers, your job, as a team, is to implement the parsing functionality. Let’s dive in.