We have our basic response status line,
and just like the request,
the status line is followed by a number of headers.
I'll 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 there,
but, the web has evolved organically over time,
so many of the headers that are--you know--
required are 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 a--you know--a would-be hacker who wants to 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's what an html page would be.
You could see image, png, or--you know--image gif--if it's an image,
that sort of thing.
And content length is how long the document that follows is--
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.
And there's other ways of also--you know--
telling the browser that I'm done sending data.
But--it's not super relevant right this second.
We've discussed the basic requests and responses,
Let's play around in the terminal a little bit,
and--you know--practice with these a little bit.
Okay-so open up a terminal,
if that is not straightforward on your machine,
we'll have some class notes 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 Telnet to make some
internet requests to web servers, and watch the http go by,
so we can see it 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 would be making
if you were loading Udacity.com in it.
It would connect to Udacity.com, port 80.
Which, if you recall--80 is the default.
Okay--so I'll hit enter, we connect,
and now 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 that machine.
Now--let's scroll back up to the top of this,
you can see the request we made--
get slash http 1.0, host: Udacity.com.
Now--why did I do 1.0?
Because the default behavior in 1.1 is--
is for the server to not close the connection--
to allow the browser to make multiple requests for 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 request,
1.0, host: Udacity.com.
And then you see the response from the server.
Here's the status line: http, 1.0, 200, okay.
So that means it worked.
And now you can see a bunch of headers.
Some of these headers we've seen and discussed before
here's date, here's 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
in 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.