{"id":210,"date":"2017-12-04T20:46:02","date_gmt":"2017-12-05T01:46:02","guid":{"rendered":"https:\/\/itp.nyu.edu\/networks\/?page_id=210"},"modified":"2019-04-04T12:36:35","modified_gmt":"2019-04-04T16:36:35","slug":"a-gentle-introduction-to-http","status":"publish","type":"page","link":"https:\/\/itp.nyu.edu\/networks\/explanations\/a-gentle-introduction-to-http\/","title":{"rendered":"A gentle introduction to HTTP"},"content":{"rendered":"

1. HT\u2026 something: HTML and HTTP<\/a><\/span><\/p>\n

2. That which we call a rose is a web resource: URIS, URLs and URNs<\/a><\/span><\/p>\n

3. Overview of the protocol: connection, request and response<\/a><\/span><\/p>\n

4. Asking nicely for content: what client requests look like<\/a><\/span><\/p>\n

5. How the server responds<\/a><\/span><\/p>\n

5.1 Common response status codes<\/a><\/span><\/p>\n

6. Further reading and resources<\/a><\/span><\/p>\n

Deeper into the \u00a0HTTP rabbithole<\/a><\/span><\/p>\n

6.2 HTTP vs. HTTPs<\/a><\/span><\/p>\n

7. Term Index<\/a><\/span><\/p>\n

Note: if you just want a quick overview of how HTTP works, head to <\/span>Section 3.<\/a><\/span>\u00a0<\/span><\/p>\n

When <\/span>Tim Berners-Lee invented the World Wide Web in 1989, \u00a0he had more in mind than just the free exchange of files around a network of computers: his design conveyed the idea of <\/span><\/a>hypertext<\/span><\/strong>\u00a0<\/span>or<\/span>\u00a0<\/span>linked documents: structured resources connected to each other through cross references that could be not only explored and retrieved in real time, but also searched, updated and even annotated on <\/span>(HTTP RFC, Section 1.1)<\/a><\/span>\u00a0through an interface. This article being delivered to you on a website through a browser is an example of such a document. It has links to related terms that you can click on and navigate to. How does this happen? <\/span><\/p>\n

<\/span>1. HT\u2026 something: HTML and HTTP<\/span><\/span><\/h2>\n

The two sister technologies that make exchanges on the Web possible are <\/span>the <\/span>Hypertext <\/span>Markup Language<\/span>\u00a0<\/span><\/a>(HTML)<\/strong> and the <\/span>Hypertext<\/span>\u00a0Transfer<\/span>\u00a0<\/span>Protocol<\/span>\u00a0<\/span><\/a>(HTTP).<\/strong> Both start with HT because they are dealing with the same stuff, hypertext, that is. <\/span><\/p>\n

HTML defines how a document should be formatted in order to play in this sharing environment we call the Web and HTTP defines<\/span>\u00a0how this document and its <\/span>resources <\/span>(see Section 2)<\/a><\/span>\u00a0get from one computer to another. Both are sets of instructions, or<\/span>\u00a0<\/span><\/a>protocols.<\/span><\/strong>\u00a0HTML defines structure, HTTP transport. <\/span><\/p>\n

Although this article does not attempt to go into too much detail into how HTML works, it is worth talking a bit about <\/span><\/a>markup<\/span>\u00a0before we delve into HTTP.<\/span><\/p>\n

The Concise Oxford English Dictionary<\/a><\/span>\u00a0defines markup, in the computational arena, as \u201ca set of tags assigned to elements of a text to indicate their relation to the rest of the text or dictate how they should be displayed\u201d. The key term to keep in mind here is <\/span><\/a>tags<\/span>. <\/span><\/strong><\/p>\n

When your human eyes rest on a document that has a certain constant visual hierarchy, you can infer which parts of it are titles, subtitles, paragraphs, lists and so on. Computers and the browsers that operate in them are not as smart. You need to tell them which parts are which with tags (Fig. 1). \u00a0<\/span><\/p>\n

\"Web<\/p>\n

A HTML tag looks like \u00a0this: <\/span><\/p>\n

\n

<title><\/span>\u00a0A gentle introduction to HTTP <\/span><\/title><\/span><\/p>\n<\/blockquote>\n

The actual tag is defined inside the characters <\/span>< > <\/>.<\/span>\u00a0The text in between is the actual content in the case of text, and other multimedia items have other rules (but don\u2019t worry about this for now). <\/span><\/p>\n

Modern HTML\u2019s standards are to a great extent designed so that tags are semantic, namely, that they accurately describe the element contained within them. \u00a0This sounds obvious, but a tag <cat> <\/cat> might not be ideal to contain information about, say, pugs. Jeffrey Zeldman and Ethan Marcotte make a strong argument on the importance of semantic structuring of documents in their <\/span>Designing with Web Standards<\/a><\/span>\u00a0 book<\/span>, which is a fantastic primer in HTML and other web technologies well worth looking into if you want to dig deeper into these subjects (you\u2019ll want to look at the 3rd edition, the most current version of this text, from 2010). <\/span><\/p>\n

So, with the idea of tagged resources in mind, let\u2019s move on to HTTP. <\/span>Why would you want to learn about it, anyway? If you are at ITP, you might want at some point create things and connect them to the Internet. If you are ready to move from your Github page or your <\/span>just another WordPress site,<\/span>\u00a0you will find useful to learn about <\/span>HTTP to get \u00a0your hyperlinked creations get out there. <\/span><\/p>\n

This document aims to be a friendly overview of how the HTTP protocol works and point to some further readings in case you want to dig deeper into the subject. <\/span><\/p>\n

<\/span>2. That which we call a rose is a web resource: URIS, URLs and URNs<\/span><\/span><\/h2>\n

Web <\/span><\/a>resources<\/span><\/strong>\u00a0take many forms. They might be text or data, images, video or other multimedia as well as information that specifies aspects of presentation and behavior\u2013like CSS and Javascript files\u2013 of \u00a0a web document. <\/span><\/p>\n

A resource is a workable\/shareable item on the internet when it has a <\/span>Unified Resource Identifier<\/span>, or <\/span><\/a>URI.<\/span><\/strong>\u00a0The URI could indicate a name of a resource, where it\u2019s located, or both. \u00a0Here\u2019s an example of a URI: <\/span><\/p>\n

\n

www.pbs.org\/video\/nova-first-man-moon\/<\/span><\/p>\n<\/blockquote>\n

You might be more familiar with the term <\/span>Unified Resource Locator,<\/span>\u00a0or <\/span><\/a>URL<\/strong>.<\/span>\u00a0URLs are URIs that in addition of pointing to the resource, they also indicate the mechanism to access it (like HTTP, HTTPs or FTP). This is what you see on your address\/search bar. Following with our previous example, a URL will look like this: <\/span><\/p>\n

http:\/\/<\/span>www.pbs.org\/video\/nova-first-man-moon\/<\/span><\/p><\/blockquote>\n

Another term that you might run into is <\/span>Unified Resource Name <\/span>or <\/span><\/a>URN,<\/span><\/strong>\u00a0which would look like the first example: \u00a0<\/span><\/p>\n

\n

www.pbs.org\/video\/nova-first-man-moon\/<\/span><\/p>\n<\/blockquote>\n

This can be a very confusing rabbit hole to dive into, the important thing to remember is that all three terms refer roughly to the same thing, but when you have an address to a resource that indicates the method to get it (eg.: HTTP:\/\/), you are looking at a URL. All URLs are URIs, but not all URIs are URLs (they can just be URNs). The bigger group is URIs (Figure 2). \u00a0If you want to keep ruminating on this <\/span>all roses are red (supposing they were), but not all red things are roses<\/span>\u00a0thread check out <\/span>Daniel Miessler\u2019s<\/a><\/span>\u00a0article<\/span>\u00a0on the subject.<\/span><\/p>\n

\"Illustration<\/p>\n

<\/span>3. Overview of the protocol: connection, request and response<\/span><\/span><\/h2>\n

The two main players that make use of the HTTP protocol are <\/span><\/a>clients <\/span><\/strong>and <\/span><\/a>servers.<\/span><\/strong>\u00a0This is how they tango: clients <\/span>request to be <\/span>connected <\/span>to a certain server from where they want to pull up resources and the server accepts the connection. If this goes well then the client will <\/span>request<\/span>\u00a0content and the server with <\/span>respond <\/span>with the requested resource. Both clients and servers are<\/span>\u00a0<\/span>software programs. In<\/span>\u00a0<\/span>between these two there may be additional middlemen often referred to as <\/span>proxies<\/span>\u00a0that do a number of additional things (like logging in, filtering, caching, etc.), but they are beyond the scope of this article, but a good resource to look at if you want to learn more is the <\/span>Mozilla Developer Network documentation on HTTP).<\/a><\/span>\u00a0<\/span><\/p>\n

For this overview we are assuming that all sides are completely functional and playing by the rules (we will briefly mention how the server responds in case something goes wrong in <\/span>Section 5).<\/a><\/span>\u00a0 So the mechanics of the HTTP protocol can be divided into three main chunks: connection, request and response (Figure 3). <\/span><\/p>\n

\"A<\/p>\n

The <\/span>World Wide Web Consortium,<\/a><\/span>\u00a0<\/span>or W3C, provided a very \u00a0straightforward description of how this breaks down (note, this is from the 1991 specification, but the mechanics remain roughly the same): <\/span><\/p>\n

    \n
  1. The client and server establish a <\/span><\/a>connection,<\/span><\/strong>\u00a0technically called a <\/span><\/a>session.<\/span><\/strong><\/li>\n<\/ol>\n
      \n
    1. The client starts off by asking to make a <\/span>TCP\/IP<\/span>\u00a0connection to the server using the <\/span>domain name<\/span>\u00a0(eg. http:\/\/<\/span>bobcat.library.nyu.edu<\/span>\/) or its <\/span>IP number<\/span>\u00a0equivalent (128.122.149.83, in the case of our example site) and the specific <\/span>port<\/span>\u00a0<\/span>number<\/span>\u00a0given in the address (Borrowing a metaphor from Charles Severance\u2019s <\/span>introductory course to Internet technologies<\/a><\/span>, if a domain name or IP were to be taken as a phone number for an organization, a port would be the <\/span>extension<\/span>\u00a0to locate a specific person inside this organization, here are some <\/span>common port numbers).<\/a><\/span>\u00a0<\/span><\/li>\n
    2. The server accepts the connection.<\/span><\/li>\n<\/ol>\n
        \n
      1. The client sends a request to the server. A request is a document, or a set of <\/span>ASCII characters<\/a><\/span>\u00a0where it defines what it wants to do with the server (it might want to get a specific resource, post information to the server, or even delete stuff from it. More on this on <\/span>Section 4).<\/a><\/span>\u00a0<\/span><\/li>\n
      2. The server answers to the client\u2019s request with a document in HTML format (this is the actual resource a browser requests) and a message to notify the client if it has been successful or not in attending its demands (see <\/span>Section 5<\/a><\/span>\u00a0for some examples of these responses). <\/span><\/li>\n<\/ol>\n
          \n
        1. The server ends the connection, or the session, when the full resource has been transferred. <\/span><\/li>\n<\/ol>\n

          This article will not cover TCP\/IP connection and will take it as a given, this is, we will assume this part is running smoothly and the parts don\u2019t close the connection until the whole transaction has been made and we will proceed to an overview of requests and responses.<\/span><\/p>\n

          <\/span>4. Asking nicely for content: what client requests look like<\/span><\/span><\/h2>\n

          When you request through your browser to access a certain website, you don’t receive all the content at once (although it sure feels like it!) Rather, all the components that make up that site are sent by the server as a series of requests for different resources that, like puzzle pieces, the browser then interprets, assembles and displays on your screen. <\/span><\/p>\n

          Clients manifest in the form of <\/span><\/a>user agents <\/span><\/strong>(this is probably the name you\u2019ll run into when looking at other HTTP documentation)<\/span>\u00a0and the most common one is the <\/span><\/a>web browser<\/span>. <\/span><\/strong><\/p>\n

          Other user agents that you might have heard of are spiders (or website bots, the ones that Google uses to link pages to its search engine) phone apps, programs working on your computer that are connected to the Internet without the aid of a browser, \u00a0Internet of Things (IoT) devices (like Amazon\u2019s Echo or Google Home), amongst other tools that may or may not have a human user behind them. <\/span><\/p>\n

          Different user agents will have different content needs and HTTP is flexible enough to cater to many client needs. When the Echo speaker connects to the Internet, for example, it has no use for images, so the server could potentially send to it a different document than the one that would be delivered to your browser. Let\u2019s stick with the browser case, as we have throughout this article, as this is probably the client you are most familiar with. <\/span><\/p>\n

          It is also important to remember from <\/span>Section 3,<\/a><\/span>\u00a0that you, as the user utilizing a client\/user agent (your browser), are always the one that starts the conversation, that is, you request information, and you do so using the rules set by HTTP.<\/span>\u00a0<\/span><\/p>\n

          So, you might be wondering, how does your browser asks for information in a polite, protocol-complying manner? <\/span><\/p>\n

          Well, it makes a specific <\/span><\/a>request<\/span><\/strong>\u00a0defining what it wants to do with the server. Requests have the following elements: <\/span><\/p>\n