You've already seen some HTTP responses, but

let me pull one up just to refresh, so telnet httpbin.org 80.

And I'll GET the resource /xml using HTTP

version 1.1 at the HOST httpbin.org.

Upon making this request, what comes up soon thereafter is the response.

This HTTP response is formatted in mostly the same way, so let's check it out.

The first line is the status line, which starts out exactly the way the request

line ended, with http/ then the version number, currently, 1.1.

Then comes the response code, then a space, then the status message.

We could spend an entire course talking about response codes and

messages but this is not that course.

Some that you should be familiar with are 200 level codes which, in general,

are success messages.

Particularly the response code 200 which is a message meaning okay.

Another you've seen is 404, which has the message not found.

Other 400 level codes, in general,

refer to something that went wrong in the client's request.

You also may see a response code in the 300s,

which indicates that the resource requested may have moved.

But in any case, the rest of the response contains instructions about where to

go next, that is, where to redirect.

Finally, there are 500 level error codes, which is used for

indicating that something went wrong on the server while processing the request.

Remember, a 500 level code means that something went wrong on the server.

Moving on, following the status line is a section of headers.

This section is formatted in the same way as request headers, with a header name,

then a colon and a space, followed by the value for that header.

These headers communicate information about the response, metadata, so to speak.

In our example, the headers include the type of server handling the request,

nginx in this case.

The exact date and time the response was went and

the type of content that's included in the body below, in this case, XML.

When the response includes HTML you'll see a content type of text/HTML.

Following the list of headers is a blank line, and then comes the response body,

which is also called the payload.

In this case, we made a request to the XML resource, so

the response body or payload is the actual XML that comes back.

If we had requested HTML, the payload would contain the HTML that comes back.

Now that you've seen the general format of HTTP, there's one point I'd like

to drive home in this request response cycle of an HTTP conversation.

And that is that HTTP itself is what's called a stateless protocol.

Stateless means that there's no record of previous interactions, and

each interaction is processed with only with

the information that comes with that particular interaction.

Put it in different way, that means that there is nothing adherent at HTTP that

allows it to remember a previous request and use it to inform a later one.

When a web application appears as if it remembers a previous request,

like remembering your user name when you return to Facebook,

this is a feature that's part of an application that using HTTP.

But not part of HTTP itself.

HTTP messages are like self-destructing notes that disappear after they're read.

Okay, you get it, HTTP is stateless.