Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
You've seen the format of an HTTP request, so in this video we discuss the format of an HTTP response. The format is very similar to requests, and consists of four parts: (1) a status line, (2) a series of headers in name/value pairs that are on lines of their own, (3) a blank line, and (4) the response body.
You've already seen some HTTP responses,
but
0:00
let me pull one up just to refresh,
so telnet httpbin.org 80.
0:04
And I'll GET the resource /xml using HTTP
0:09
version 1.1 at the HOST httpbin.org.
0:13
Upon making this request, what comes
up soon thereafter is the response.
0:18
This HTTP response is formatted in mostly
the same way, so let's check it out.
0:23
The first line is the status line, which
starts out exactly the way the request
0:29
line ended, with http/ then
the version number, currently, 1.1.
0:33
Then comes the response code,
then a space, then the status message.
0:37
We could spend an entire course
talking about response codes and
0:43
messages but this is not that course.
0:47
Some that you should be familiar with
are 200 level codes which, in general,
0:49
are success messages.
0:54
Particularly the response code 200
which is a message meaning okay.
0:55
Another you've seen is 404,
which has the message not found.
1:02
Other 400 level codes, in general,
1:07
refer to something that went
wrong in the client's request.
1:10
You also may see a response
code in the 300s,
1:15
which indicates that the resource
requested may have moved.
1:18
But in any case, the rest of the response
contains instructions about where to
1:21
go next, that is, where to redirect.
1:26
Finally, there are 500 level error codes,
which is used for
1:29
indicating that something went wrong on
the server while processing the request.
1:33
Remember, a 500 level code means that
something went wrong on the server.
1:38
Moving on, following the status
line is a section of headers.
1:43
This section is formatted in the same way
as request headers, with a header name,
1:48
then a colon and a space,
followed by the value for that header.
1:52
These headers communicate information
about the response, metadata, so to speak.
1:56
In our example, the headers include
the type of server handling the request,
2:01
nginx in this case.
2:05
The exact date and
time the response was went and
2:07
the type of content that's included
in the body below, in this case, XML.
2:10
When the response includes HTML you'll
see a content type of text/HTML.
2:15
Following the list of headers is a blank
line, and then comes the response body,
2:21
which is also called the payload.
2:25
In this case,
we made a request to the XML resource, so
2:27
the response body or
payload is the actual XML that comes back.
2:31
If we had requested HTML, the payload
would contain the HTML that comes back.
2:36
Now that you've seen the general format
of HTTP, there's one point I'd like
2:42
to drive home in this request response
cycle of an HTTP conversation.
2:46
And that is that HTTP itself is
what's called a stateless protocol.
2:50
Stateless means that there's no
record of previous interactions, and
2:56
each interaction is
processed with only with
3:01
the information that comes with
that particular interaction.
3:03
Put it in different way, that means that
there is nothing adherent at HTTP that
3:07
allows it to remember a previous request
and use it to inform a later one.
3:13
When a web application appears as
if it remembers a previous request,
3:18
like remembering your user name
when you return to Facebook,
3:22
this is a feature that's part of
an application that using HTTP.
3:25
But not part of HTTP itself.
3:29
HTTP messages are like self-destructing
notes that disappear after they're read.
3:33
Okay, you get it, HTTP is stateless.
3:38
You need to sign up for Treehouse in order to download course files.
Sign up