HTTP Protocol Tutorial

By Xah Lee. Date: . Last updated: .

In 10 minutes, you'll have a basic understanding of HTTP protocol.

Here's a summary of what HTTP protocol is:

For example, when you use web browser to view a URL, the following happens:

  1. Browser send a request to a server. (Server address is contained in the URL.)
  2. The server sends back response, also plain text. (if it is image file, the image is encoded into text.)
  3. The browser renders the result. (if it is HTML, browser parses it, and may make other requests such as images, style sheet, JavaScript file, etc.)

To understand HTTP protocol, we just need to understand the HTTP messages that the client/server send. Let's first look at tools to view HTTP messages.

How to See HTTP Messages

See HTTP Headers in Web Browser

you can use web browser to view the header sent/received by client/server.

http protocol headers chrome browser 2019-03-11 x7s7r
Google Chrome browser showing HTTP message headers.

Here's how to use Google Chrome to view HTTP messages:

  1. Open the web development tool. (in Google Chrome, press F12 on Windows or Linux. Other browsers/OS have similar tool. You can find it in their menu.)
  2. Click on the Network tab.
  3. Visit some page, type a URL in the URL box and press Enter.
  4. Click on a item in the left of the network report, to see the HTTP message header for that item. (each item is a HTTP request made by browser.)

Linux Command to View HTTP Headers

The following command line tools can view HTTP response header.

Here's curl example:

curl --head example.com

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Type: text/html; charset=UTF-8
Date: Mon, 11 Mar 2019 04:25:57 GMT
Etag: "1541025663"
Expires: Mon, 18 Mar 2019 04:25:57 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (sjc/4E4E)
X-Cache: HIT
Content-Length: 1270

Here's wget example:

wget --server-response --spider example.com

Spider mode enabled. Check if remote file exists.
--2019-03-10 21:29:03--  http://example.com/
Resolving example.com (example.com)... 2606:2800:220:1:248:1893:25c8:1946, 93.184.216.34
Connecting to example.com (example.com)|2606:2800:220:1:248:1893:25c8:1946|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Content-Encoding: gzip
  Accept-Ranges: bytes
  Cache-Control: max-age=604800
  Content-Type: text/html; charset=UTF-8
  Date: Mon, 11 Mar 2019 04:29:03 GMT
  Etag: "1541025663"
  Expires: Mon, 18 Mar 2019 04:29:03 GMT
  Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
  Server: ECS (sjc/4E45)
  X-Cache: HIT
  Content-Length: 606
Length: 606 [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.

[see Linux: Download Website: wget, curl]

Other languages, such as Python and Ruby, have similar tools or libraries.

Client/Server Messaging

Sample message sent by client:

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

Sample message sent by server:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

Lines in HTTP message must be separated by the character sequence "\r\n". (that is, a carriage return followed by a line feed. Yes, both.) [see ASCII Table]

The message exchanged by client/server is plain text. It has 2 parts, header and content.

Header and content are separated by 1 blank line.

The first line of the header is special.

If it's request, it's called request line. For example, it looks like this:

GET /tutorial/index.html HTTP/1.1

If it's response, it's called status line. For example, it looks like this:

HTTP/1.1 200 OK

The rest of header part is made of lines, each line is called a “field”.

A field is separated by first colon : into two parts: field-name and field-value.

HTTP Methods

Recall that the first line of request looks like this: GET /tutorial/index.html HTTP/1.1

It has 3 parts: ① request method. ② resource path. ③ http version.

The most used request methods are:

GET
Request a resource.
HEAD
Same as GET, but only get headers, no content. That is, just request metadata. Useful for web crawler, proxy server, etc.
POST
Send some info to server. For example, used for login, credit card, shopping cart, via HTML Form. [see HTML Form Example]

Other methods are much less used , and may not be implemented by server.

The following is a more complete list from HTTP/1.1 (source is Wikipedia 2019-03-11)

GET
Requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.) The W3C has published guidance principles on this distinction, saying, “Web application design should be informed by the above principles, but also by the relevant limitations.” See safe methods below.
HEAD
Asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.
POST
Requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database.
PUT
Requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.
DELETE
Deletes the specified resource.
TRACE
Echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.
OPTIONS
Return the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting ‘*’ instead of a specific resource.
CONNECT
Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy. See HTTP CONNECT method.
PATCH
The PATCH method applies partial modifications to a resource.

For detail about the commands, see: [RFC 7231 HTTP/1.1: Semantics and Content By IETF. At https://tools.ietf.org/html/rfc7231 , accessed on 2016-04-02 ]

HTTP Status Code

In the server response message, the first line is the status line. Here's a example:

HTTP/1.1 200 OK

It has 3 parts: ① the HTTP version. ② the status code. ③ Human readable representation of the status code.

The status code has 3 digits. Its meaning is grouped into categories by the first digit:

1xx (Informational)
The request was received, continuing process
2xx (Successful)
The request was successfully received, understood, and accepted
3xx (Redirection)
Further action needs to be taken in order to complete the request
4xx (Client Error)
The request contains bad syntax or cannot be fulfilled
5xx (Server Error)
The server failed to fulfill an apparently valid request

Here's a full list. Those with a 🌟 sign are most frequently used.

100
Continue
101
Switching Protocols
200
🌟 OK
201
Created
202
Accepted
203
Non-Authoritative Information
204
No Content
205
Reset Content
206
Partial Content
300
Multiple Choices
301
🌟 Moved Permanently
302
Found
303
See Other
304
Not Modified
305
Use Proxy
307
Temporary Redirect
400
Bad Request
401
Unauthorized
402
Payment Required
403
🌟 Forbidden
404
🌟 Not Found
405
Method Not Allowed
406
Not Acceptable
407
Proxy Authentication Required
408
Request Timeout
409
Conflict
410
Gone
411
Length Required
412
Precondition Failed
413
Payload Too Large
414
URI Too Long
415
Unsupported Media Type
416
Range Not Satisfiable
417
Expectation Failed
426
Upgrade Required
500
Internal Server Error
501
Not Implemented
502
Bad Gateway
503
Service Unavailable
504
Gateway Timeout
505
HTTP Version Not Supported

For detail of all status code, see: [RFC 7231 HTTP/1.1: Semantics and Content By IETF. At https://tools.ietf.org/html/rfc7231 , accessed on 2016-04-02 ]

HTTP Cookies

Cookies is also sent as part of the HTTP header.

What is a cookie?

Basically, when server responds, it can return a header such as Set-Cookie: name=value. When browser sees that, the browser is required to store it locally, along with which server the cookie came from. When browser makes a request to a server, browser must also send all cookies that the same server sent before.

The purpose of cookies is for server to keep states of clients. For example, by setting a cookie, the server is able to know if the browser user is logged in.

For detail on how cookies work, see:

JavaScript: Checking, Getting, Setting, Cookies

The TCP/IP Protocol Suite

The HTTP protocol is a high-level application layer protocol of the TCP/IP internet protocol suite. HTTP protocol is about client/server exchanging messages.

But how exactly do browser find server across the globe? and How does browser send message exactly, by airplane?

The details of how client/server communicate, is specified by many lower protocols in TCP/IP. For a basic introduction, see TCP/IP Tutorial for Beginner .

Reference

HTTP/2 [Hypertext Transfer Protocol Version 2 (HTTP/2) By IETF. At https://tools.ietf.org/html/rfc7540 , accessed on 2016-04-01 ]

obsolete. [Hypertext Transfer Protocol -- HTTP/1.1 By IETF. At https://tools.ietf.org/html/rfc2616 , accessed on 2016-04-02 ]

Networking Tutorial