What is HTTP? — HTTP/HTTPS protocols

The language of the web

Every time you visit a website, submit a form, or load an image, your browser is having a conversation with a server. That conversation follows a strict set of rules called HTTP: HyperText Transfer Protocol.

HTTP is the foundation of all data exchange on the web. Without it, browsers wouldn't know how to ask for pages, and servers wouldn't know how to respond.

A simple analogy

Think of HTTP like ordering food at a restaurant:

You (client/browser):    "I'd like the homepage, please."  → HTTP Request
Waiter (the internet):    carries your order to the kitchen
Kitchen (server):         prepares the dish
Waiter:                   brings back the plate
You:                      receive the food                  ← HTTP Response

HTTP is a request-response protocol. The client always asks first, and the server always answers. The server never sends data unprompted.

HTTP in action

When you type https://example.com in your browser, here's what happens at the HTTP level:

1. Browser creates an HTTP REQUEST:
   GET / HTTP/1.1
   Host: example.com

2. Server processes the request and sends an HTTP RESPONSE:
   HTTP/1.1 200 OK
   Content-Type: text/html

   <html><body>Hello, World!</body></html>

3. Browser reads the response and renders the HTML

That's it. Every web interaction (loading pages, submitting forms, fetching API data) follows this same pattern.

Key characteristics of HTTP

1. Stateless

HTTP is stateless: each request is completely independent. The server doesn't remember previous requests.

Request 1: GET /products      → Server responds with product list
Request 2: GET /products/42   → Server has NO memory of Request 1

This means the server treats every request as if it's from a brand new visitor. To maintain state (like "this user is logged in"), web apps use cookies and sessions: but HTTP itself doesn't track anything.

Why stateless? It makes servers simpler and more scalable. Any server in a cluster can handle any request without needing to know what happened before.

2. Text-based

HTTP/1.1 messages are human-readable text, so you can read raw HTTP (HTTP/2 and HTTP/3 send the same messages in binary frames, and tools decode them for you):

GET /about HTTP/1.1
Host: myapp.com
Accept: text/html
User-Agent: Mozilla/5.0

This makes HTTP easy to debug: you can inspect what's being sent and received.

3. Client-server architecture

HTTP clearly separates roles:

sequenceDiagram
  participant C as Client (browser)
  participant S as Server (Rails)
  C->>S: request
  S->>C: response

Client initiates requests (browsers, mobile apps, curl, API clients)
Server listens and responds (Rails, Django, Express, etc.)

4. Runs over TCP

HTTP rides on top of TCP (Transmission Control Protocol), which you learned about in the Internet Fundamentals course. TCP ensures that HTTP messages arrive complete, in order, and without corruption. (HTTP/3 is the exception: it runs over QUIC, on UDP.)

Application Layer:   HTTP (your web request)
Transport Layer:     TCP  (reliable delivery)
Network Layer:       IP   (routing across the internet)

The anatomy of a URL in HTTP

HTTP requests target a specific resource identified by a URL:

https://myapp.com:443/courses/ruby-basics?page=2#overview
│       │          │   │                  │       │
scheme  host      port path              query   fragment

Part	Purpose	Example
Scheme	Protocol to use	`http://` or `https://`
Host	Server to connect to	`myapp.com`
Port	Server port (default: 80/443)	`:443`
Path	Which resource to request	`/courses/ruby-basics`
Query	Additional parameters	`?page=2`
Fragment	Client-side anchor (NOT sent to server)	`#overview`

Important: The fragment (#overview) is never sent to the server. It's used only by the browser to scroll to a section on the page.

HTTP methods (verbs): a preview

HTTP defines several methods (also called verbs) that tell the server what action to perform:

Method	Purpose	Example
GET	Retrieve data	View a webpage
POST	Create data	Submit a form
PUT	Replace data entirely	Update a full record
PATCH	Update data partially	Change one field
DELETE	Remove data	Delete a record

You'll study each verb in depth in upcoming courses. For now, know that GET and POST account for the vast majority of web traffic.

HTTP status codes: a preview

Every HTTP response includes a status code: a three-digit number indicating the result:

Range	Meaning	Example
1xx	Informational	100 Continue
2xx	Success	200 OK
3xx	Redirection	301 Moved Permanently
4xx	Client Error	404 Not Found
5xx	Server Error	500 Internal Server Error

You'll study specific status codes in detail later. The key takeaway: the first digit tells you the category of the response.

HTTP and Rails

Rails is fundamentally an HTTP framework. When you create a Rails application, you're building a program that:

Receives HTTP requests (via a web server like Puma)
Routes them to the right controller action
Processes the request (queries database, runs business logic)
Returns an HTTP response (HTML, JSON, redirect, etc.)

Browser: GET /courses HTTP/1.1
         Host: myapp.com

         ↓

Rails:   routes.rb → CoursesController#index
         → queries database
         → renders view

         ↓

Browser: HTTP/1.1 200 OK
         Content-Type: text/html
         <html>...course list...</html>

Every Rails concept (routes, controllers, views, redirects, form submissions) maps directly to HTTP concepts. Understanding HTTP is understanding how Rails thinks.

Summary

Concept	Key Point
HTTP	HyperText Transfer Protocol: the language browsers and servers speak
Request-Response	Client asks, server answers: always in that order
Stateless	Each request is independent: server doesn't remember previous ones
Text-Based	HTTP messages are human-readable: easy to debug
Client-Server	Clear separation: client initiates, server responds
Over TCP	HTTP relies on TCP for reliable, ordered delivery
Methods	GET, POST, PUT, PATCH, DELETE: tell the server what to do
Status Codes	2xx success, 3xx redirect, 4xx client error, 5xx server error
Rails	A framework for receiving HTTP requests and returning HTTP responses