HTTP - CS50 Shorts

Key Takeaways

Let's talk about another protocol, the Hypertext Transfer Protocol or HTTP. So, we've talked about IP and TCP in uh in previous videos, and those are protocols that dictate how information moves from machine to machine and from program to program or service to service um via the internet, via this network of routers um and machines. But, that's usually not the entire picture, right? Usually, when we send information, the program itself, the when the when data is received, say for example, an email via TCP port 25 or uh a web page request via port 80, there's usually a system of rules there to process what I've just received. And HTTP is an example of just such a protocol. HTTP is the only application layer protocol that we're going to talk about, but it is another set of rules um dictating how information is to be transmitted and processed via the internet. In particular, HTTP specifies exactly how one must make a request for a web page, and exactly how a server, uh a machine that hosts web pages, delivers that information back to clients. So, this protocol doesn't actually have anything to do with how information moves from point A to point B. It's really the system of rules for It's basically the rules of engagement for working with a web page. Similar to when somebody waves their hand at you, you're supposed to wave back, that's sort of a conventional human protocol. An HTTP protocol just says, "If you want to request a web page, make sure your format looks like this." Sort of like formatting a business letter, for example. Um and the response will similarly come according to this protocol. There are other application layer protocols that we're not going to talk about in videos, but these include things like the File Transfer Protocol, Simple Mail Transfer Protocol for sending emails, the Data Distribution Service, Remote Desktop Protocol RDP, which is used if you want to remotely access your computer from another computer, uh XMPP, which is frequently known as Jabber or chat, so this is a protocol for using chat services, and there are many, many, many others. So, every time you're using a service, uh the service is expecting information to be received or requests to be received in a very particular format and is required to return information back in a very particular format, as well. So, let's go back to our illustration of us wanting to talk to the internet. So, we're happy and we want to go to cats.com, right? So, if we're just talking to cats.com, we might say something like, "Hey, can I see your home page?" And cats.com will probably respond, "Yeah, sure. Here you go." So, that's a human sort of ask and answer. What does that look like in HTTP? Well, it's actually kind of translates pretty cleanly to something like this. We might say, "Get / HTTP/1.1 from host cats.com." So, basically, what I'm doing here is asking for the web page www.cats.com/ We usually omit the slash nowadays, but that would just mean cats.com's home page. Oh, and by the way, I'm going to be using HTTP protocol or HTTP version 1.1 to communicate with you. That's sort of analogous to saying like, "By the way, I'm going to be speaking in French." Or, "By the way, I'm going to be speaking in English." That's just the format of the protocol. There's also 1.0, which is not commonly used anymore. So, I'm speaking HTTP 1.1, and I would like www.cats.com/ Please get that for me. And there's other information, too, the dot dot dot there, which is information about who you are, uh so it knows so cats.com would know where to send it. But, these are the two sort of critical parts at the very beginning of an HTTP request. Just like when you start a letter, you say, "Dear blank." Uh this is very similar to in spirit to that. And if cats.com is going to say, "Oh, sure, here you go." they might respond like this. I'm also responding. I also speak HTTP 1.1. Your request is approved. 200 OK. What you're about to receive is HTML, and then dot dot dot, some extra information, and at the very bottom of the request is actually the HTML, the the markup language, the content of cats.com's home page. So, HTTP/1.1, I acknowledge your request was accepted via HTTP 1.1. Your request was approved. I can I can give you what you want. 200 OK. Um you're about to receive HTML, and then here's the HTML that you requested. But, sometimes our requests don't always go quite according to plan. Can I see your cats.html page? Well, what if they say, "Uh we don't have a cats.html page." Which seems kind of unrealistic cuz they're cats.com, you'd think they'd have cats.html, but okay, so this is this is sort of the conventional human interaction we've now had with cats.com. How does that translate? This might be something familiar to you. Our request looks exactly the same, except instead of getting slash, we're now getting cats.html. So, now what basically this entire request is saying is, "Please give me www.cats.com/cats.html." So, the host and the middle part of that top line there indicates uh precisely what page I am asking for. But, cats.com in this case isn't going to be able to respond positively. They don't know what we're talking about. And so, this isn't this is something you might have seen before, HTTP 1.1 404 Not Found. I couldn't find what you were asking for. By the way, I'm going to give you back some HTML, and usually that HTML was the content of some 404 page. In the case of cats.com, it's probably some cute cats in a basket with a sad 404 face next to them because you're going to be sad when you don't get page that you were looking for. But, that that's kind of the basics of what a protocol of the HTTP protocol requests look like. They're very similar to how we would make a similar interaction in just human conventions, asking for something and getting it back or writing a letter and expecting a response letter in a particular format. Um that's pretty much what HTTP is just canonicalizing um for all devices that wish to access web pages, hypertext transfers. So, a line of the form this, the method request target HTTP version, is called an HTTP request line. It's usually the first thing that uh is transmitted as part of an HTTP request or to if you're asking for HTTP. It's sort of like, as I said, saying, "Dear blank." at the top of your letter. They know that you're writing them a letter. Um so, this is very similar to saying, "I know that they're making an HTTP request, and this is the particular format they're asking for." HTTP version is probably always going to be HTTP/1.1. 1.0 also exists, but isn't really used anymore. For purposes of CS50, get is probably always what you're going to be using when you're making when you're actually making direct HTTP requests, but post is another option we're not going to talk about right now. And then request target is what page on the host's server you would like to get. Uh as I said, that host name is a separate line, usually the second line of the overall request. And so, taken together, the host name and the request target specify a specific resource being sought. In our 404 example a second ago, I was asking again for www.cats.com, cats.com being the host, and in my request line, I said, "/cats.html." That was my request target. So, overall, I was asking for the contents or the resource located at www.cats.com/cats.html. And then based on whether the resource exists and whether the server can deliver the resource pursuant to the client's request, you might get a various status codes back. Some of these status codes you've seen because they're part of the response. Some of them, like 200 OK, are probably pretty silent. You've probably never seen a page respond 200 OK. You just get the page. It's not like a 404 error, um which is usually pretty clear. You usually see that it says 404. So, let's talk about what some of those status codes might be. Again, when they when the server responds to us, they're going to respond HTTP version status, usually HTTP 1.1. What are these status codes going to be? Well, we might get a success. So, in the success category, we might get code 200 with the text OK. What does this mean? Well, everything is good. You made a valid request. Here's a valid response. I was able to deliver exactly what you wanted. Sometimes you might get other things that you won't notice right away, but are somewhat failures. They're called redirections. There's two common ones here, 301 Moved Permanently. What this basically means is the page is now at a new location. It will live there forever, and most browsers will automatically redirect you. So, you'll never really see a 301, either, uh unless you're using a really out-of-date browser, possibly, uh because the 301 response as part of the dot dot dot of the 301 response, it also tells you where the new page is. And so, most browsers will just redirect you there, assuming that you want to go there. Sometimes you'll also get 302 Found. And this one you actually might still see occasionally. Sometimes pages move temporarily. So, it's not going to be built into the request uh a part telling the browser to permanently change uh anytime it sees the request that you make to change it to something else. Uh so, you might see 302 Found, um which basically says this page lives somewhere else, but it's not going to live there forever. It'll eventually probably go back to where um you think it is. Then you'll get things like client errors. So, these are the ones you've probably seen now. You probably haven't seen the 200s or the 300s, but you're probably familiar with the 400s, as we'll talk about in a second, 500s, as well. You might see 401 Unauthorized. Usually, this means you're trying to access a page, but you haven't logged in. So, if you try and go to some profile or something on Facebook, um or you try and access some, you know, your your at work, you're trying to access something on your work's intranet, um but you're not logged in, you can't see the page. You might get a 401 unauthorized, which means we probably will be able to satisfy this request, but first you need to log in to do so. Conversely, you might get 403 forbidden, which is it doesn't really matter if you're logged in or not, this request isn't allowed. The resource exists on the server, but you are not allowed to access it. This is usually internal files that live on the server for various reasons, but are not intended to be accessed from the outside world, and so they are forbidden. They live there. I I'm not saying I can't find it, but I'm saying I cannot give it to you, and it doesn't matter if you're logged in or not. And then of course, the very common 404 not found. I the file doesn't exist on the server. I would like to satisfy your request, but I can't. You also sometimes see server errors, the most common general and being 500 internal server error, which doesn't actually tell you uh about what has gone wrong, but it's not actually you making a mistake in your request. It's actually the uh server failing to deliver on the request somehow. So, 500 is the general response. You'll also see uh something like service unavailable, which I believe is code 503. Uh and gateway timeout. Have you ever had a page just sit there loading and loading and loading, and you never know if it's going to load, and then eventually just says I just gives up. Uh that's a 504 gateway timeout. The server wanted to execute your request, but something went wrong on the server side, not on your side, uh to cause that to be a problem. Now, we could end the story here, but what I'm actually going to do now is I'm going to open up my browser and show you how you might be able to see some of these uh status codes even if you don't generally see them. We're going to do that by taking a look at uh some developer tools. All right, so here I am now in my browser window. And I want to learn a little bit more about these HTTP requests. How do I know I certainly we know if a page goes if something goes wrong, we get a 404, we've all seen that. We don't need to illustrate that, but what are some other ones, and how would we see these requests in action? So, first thing I'm going to do is open up developer tools. So, developer tools are built into most modern browsers and allow us to uh see things that we don't otherwise see, some extra information sort of being transmitted underneath our our web requests. I'm using Google Chrome here, and to open um developer tools in Chrome, you just hit F12, and it's going to open it up on the side. Um once I type the request, I'll zoom in so we can see what's going on here, but what I'm going to do in my browser bar is, and I'll zoom in over here, I will make a request to www. google .com. We've all probably made this request before, and I'm going to hit enter. Now, over here in my developer tools, I've chosen the network tab. And you notice a lot of things here. Look at these 200 okay, 200 okay, some of these status codes coming up. I know I'm getting a 302 found. I didn't realize I'd see that one. But basically, notice that pretty much in terms of my Google request, I made a very simple request for Google's page, and in in the process of delivering my request, uh Google has apparently made a lot of other requests on my behalf. But um yeah, I've made a get request for Google's page, and I'm getting a lot of 200 okay's. I'm not seeing 200 okay on my screen, but I'm getting a lot of requests that have been made. One more that I'm pretty sure is going to work is for those of you who are really old school, you may know that Facebook was not always at facebook.com. Uh in its early days, it was at www.thefacebook.com. They apparently could not get access to facebook.com for quite a while. And so, what I'm expecting here is to get information, and we'll see if this pans out. Uh what I'm expecting here is to get information that Facebook has moved permanently from thefacebook.com to facebook.com. So, I'm expecting somewhere near the top of my requests over in my uh developer tools to get a 301 notification that Facebook has moved permanently. Again, I won't see 301 built I won't see 301 on my browser screen. Um and because it's a 301, it's a permanent move, my browser, being that it's a modern browser, is probably going to redirect me to facebook.com anyway. But let's see what happens. So, now I'm going to go to thefacebook.com. And yep, there it is, right at the top. It went away, but it was there. Let me scroll up here. Right here at the top, I made a request to thefacebook.com, and I'm getting a response that this page has moved permanently. And then 307 here is an internal redirect, and so this is what has actually moved me to the much more familiar www.facebook.com. Um so, these these response codes do still happen even if we don't see them. I'm not going to illustrate 401, 403, 404, because you've probably seen those at various points, and 500 I would just be kind of we get lucky if we got a 500, because we don't I don't know what servers are currently down um anywhere. But um these codes do exist, and there is a way to access them even if we don't see them uh first hand on our systems. I'm Doug Lloyd. This is CS50.