We have our basic response status line and just like the request, the status line is followed by a number of headers. I give you a few examples. Here are some headers that are commonly included with http responses. Now just like the client request, the headers that you see aren’t always the same. Some of them are required and when I say required I mean usually they are, but the web has evolved organically over time, so many of the headers that are you know, required are you know, often not there or things will work without them but anyway, okay. So date is there all the time. That’s when the request happens. You know, no surprise there. Server, this is similar to the user agent header on the request. This is the, generally the name and version number of the server that’s handling the response. Now, personally, I try to never include this. Or if I do include it, I make something up, because otherwise you’re just giving free information to you know, a would-be, a would-be hacker who wants to know, you know, which vulnerabilities work against you. Content type, very popular. This is the type of document that’s being returned. This is so your browser knows how to display it. So text html is a common one, obviously, you know, that, that’s what an HTML page would be. You could see image PNG or, you know, image GIF, you know, if, if, if it’s an image that sort of thing. And content length is how long the document that follows this. Content length is often included but it’s not strictly required because the browser will know when the document’s done receiving data because the connection may close. There are other ways of also telling the browser that I am done sending data, but it is not super relevant right this second. We have discussed the basic requests and responses. Let’s let’s play around in the terminal a little bit and you know, practice with these a bit. Okay, so open up a terminal if that is not straight forward on your machine we’ll have some class notes on on how to do that. You Windows users might have some challenges in front of you. So we’re in our terminal and we’re going to use a program called tell net to make some Internet requests to web servers and watch the http go by. So we can see them in practice. Okay. So, let’s make a request. Okay. I’m making a request to udacity.com port 80. This is the request your browser will be making if you are loading udacity.com in it. Here we connected to udacity.com port 80 which, if you recall, 80 is the default. Okay, so I’ll hit enter. We connect and I’m going to send the request line that we talked about before. And I’m going to send an HTTP 1.0 and I’ll explain why in a second. And I’m going to include the host header. Google wants this because, as we discussed before, it’s hosting a lot of different web servers on a machine. Now, let’s scroll back up to the top of this. You can see the request we made, get/HTTP 1.0, host udacity.com. Now, why did I do 1.0? Because the default behavior in 1.1 is to, is for the server to not close the connection. To allow the browser to make multiple requests from multiple things. Which is an optimization, but when you’re testing by hand, it means the connection stays open, and then you have to close the connection on your machine, which is, you know, when you’re using telnet is sometimes a little bit of a pain. So we see our response or our request, 1.0, host, udacity.com, and then you see the response from the server. Here’s the status line. HTTP/1.0 200 OK. So, that means it worked, and now you can see a bunch of headers. Some of these headers we’ve, we’ve seen and discussed before. Here’s date. Here is the server, it’s Google front end. Here’s the content type, text HTML, that means we’re receiving HTML, which is no big surprise. And if we scroll down following the status line on the headers, we see the actual response document. And this is HTML. This is the type of stuff we were working on before. This is complex but you get the idea. Lots of HTML.