HTTP Fundamentals

The Protocol of the Web

"HTTP is the foundation of all data communication on the World Wide Web. Every time you load a page, submit a form, or call an API, HTTP is the protocol carrying your request."

CSE 135 — Full Overview | Review Questions

← → sections  •  ↓ more detail

Section 1What is HTTP?

An application-layer, client-server, stateless, request-response protocol.

Key Characteristics

  • Client-server: One side requests, the other responds. Server never initiates.
  • Stateless: Each request is independent — server doesn't remember previous requests.
  • Text-based (HTTP/1.x): Human-readable messages (HTTP/2+ uses binary framing).
  • Runs on TCP (or QUIC): HTTP/1.x and HTTP/2 use TCP; HTTP/3 uses QUIC (UDP).
Client Server ┌──────────────┐ ┌──────────────┐ │ Browser │ GET /index.html HTTP/1.1 │ Web Server │ │ curl │ Host: example.com │ (Apache, │ │ fetch() │ ──────────────────────────▶ │ Nginx, │ │ │ ◀────────────────────────── │ Node.js) │ │ │ HTTP/1.1 200 OK │ │ └──────────────┘ └──────────────┘
HTTP is an application-layer protocol. It only cares about the structure and meaning of requests and responses — not routing (IP) or delivery (TCP/QUIC).
Read full section →

Section 2HTTP Versions

Same semantics, better performance — from one-request-per-connection to multiplexed streams.

Version Comparison

VersionYearKey FeaturesConnection Model
HTTP/0.91991GET only, no headers, HTML onlyOne request per connection
HTTP/1.01996Headers, status codes, POST, Content-TypeOne request per connection
HTTP/1.11997Persistent connections, chunked transfer, Host headerKeep-alive (reuse connections)
HTTP/22015Binary framing, multiplexing, HPACK compressionSingle connection, multiplexed streams
HTTP/32022QUIC transport (UDP), no head-of-line blockingQUIC with multiplexed streams
HTTP/1.1 is what you'll see in raw examples, curl output, and DevTools. HTTP/2 and HTTP/3 are performance upgrades — the semantics (methods, headers, status codes) are identical.
Read full section →

Section 3The Request-Response Cycle

Every HTTP interaction: client sends a request, server sends a response. Both follow the "Law of Three."

The Law of Three

PartRequestResponse
1. Start lineRequest line: GET /page HTTP/1.1Status line: HTTP/1.1 200 OK
2. HeadersHost, Accept, User-Agent, etc.Content-Type, Content-Length, etc.
3. BodyOptional (POST, PUT, PATCH)Optional (HTML, JSON, image, etc.)
── Request ───────────────────────────────────────── GET /api/books HTTP/1.1 ← Request line Host: example.com ← Required in HTTP/1.1 Accept: application/json ← Client wants JSON ← Blank line (no body for GET) ── Response ──────────────────────────────────────── HTTP/1.1 200 OK ← Status line Content-Type: application/json ← Server sends JSON Content-Length: 82 ← Body size in bytes ← Blank line [{"id":1,"title":"HTTP Guide"},{"id":2,"title":"REST in Practice"}]
Read full section →

What Happens When You Type a URL

Browser DNS Server Web Server (example.com) │ │ │ │ 1. DNS Lookup │ │ │ "What IP is example.com?" │ │ │ ─────────────────────────────▶│ │ │ "93.184.216.34" │ │ │ ◄─────────────────────────────│ │ │ │ │ │ 2. TCP Three-Way Handshake │ │ SYN ──────────────────────────────────────────────▶│ │ SYN-ACK ◄───────────────────────────────────────────│ │ ACK ──────────────────────────────────────────────▶│ │ │ │ 3. TLS Handshake (HTTPS only) │ │ ClientHello ──────────────────────────────────────▶│ │ ServerHello + Certificate ◄───────────────────────│ │ [Encrypted connection established] │ │ │ │ 4. HTTP Request │ │ GET /page HTTP/1.1 ───────────────────────────────▶│ │ │ │ 5. HTTP Response │ │ HTTP/1.1 200 OK ◄────────────────────────────────│ │ │ │ 6. Browser renders HTML (may trigger more requests) │

Steps 2 and 3 (TCP + TLS) only happen for the first request. Subsequent requests reuse the connection.

Read full section →

Section 4HTTP Request Structure

Request line + headers + blank line + optional body.

Annotated Request

┌─ Request Line ────────────────────────────────────┐ POST /api/books HTTP/1.1 └───────────────────────────────────────────────────┘ ┌─ Headers ─────────────────────────────────────────┐ Host: example.com Content-Type: application/json Content-Length: 48 Authorization: Bearer eyJhbGci... └───────────────────────────────────────────────────┘ ← BLANK LINE (CRLF) ┌─ Body ────────────────────────────────────────────┐ {"title": "New Book", "author": "Jane Doe"} └───────────────────────────────────────────────────┘

Request Line Anatomy

METHOD /path HTTP/version — exactly three parts:

  • Method: What action to perform (GET, POST, PUT, DELETE, etc.)
  • Request target: The path of the resource (/api/books)
  • HTTP version: Almost always HTTP/1.1
The blank line between headers and body is not optional. It's a CRLF that tells the parser "headers are done." Omit it and the request is malformed.
Read full section →

Section 5HTTP Response Structure

Status line + headers + blank line + optional body. Same three-part structure as requests.

Three Response Examples

── 200 OK (HTML) ─────────────────────────────────── HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 137 <!DOCTYPE html><html>...</html> ── 201 Created (JSON + Location) ─────────────────── HTTP/1.1 201 Created Content-Type: application/json Location: /api/books/42 {"id": 42, "title": "HTTP Guide"} ── 404 Not Found (JSON Error) ────────────────────── HTTP/1.1 404 Not Found Content-Type: application/json {"error": "Not Found", "message": "No book with ID 999"}
Status code and body format are independent. A 404 can return HTML (for browsers) or JSON (for APIs). The Content-Type header tells the client how to interpret the body.
Read full section →

Section 6HTTP Methods

Verbs that indicate the desired action: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS.

Core Methods

MethodPurposeBody?Safe?Idempotent?
GETRetrieve a resourceNoYesYes
POSTSubmit data / createYesNoNo
PUTReplace entirelyYesNoYes
PATCHPartial modifyYesNoNo
DELETERemove a resourceOptionalNoYes
HEADGET without bodyNoYesYes
OPTIONSCommunication optionsOptionalYesYes
Read full section →

Less Common Methods & Semantics

  • TRACE: Echoes the request back (debugging; usually disabled for security)
  • CONNECT: Establishes a tunnel through a proxy (used by HTTPS through HTTP proxies)
Methods have semantics. GET means "read," POST means "create/submit," PUT means "replace," DELETE means "remove." Using them correctly lets infrastructure (caches, proxies, browsers) optimize accordingly.
Read full section →

Section 7Safety & Idempotency

Two properties that define how methods behave — and determine what's safe to cache, retry, and prefetch.

The 2×2 Grid

│ Safe (read-only) │ Unsafe (may modify) ─────────────────────┼───────────────────────┼─────────────────────── │ │ Idempotent │ GET, HEAD, OPTIONS │ PUT, DELETE (repeatable) │ │ │ Repeat all you want │ Repeat safely — same │ — no side effects │ result every time ─────────────────────┼───────────────────────┼─────────────────────── │ │ Non-Idempotent │ (none) │ POST, PATCH (not repeatable) │ │ │ │ Repeating may create │ │ duplicates

Why This Matters

  • Caching: Only safe methods (GET, HEAD) are cached by default
  • Retries: Idempotent methods (GET, PUT, DELETE) are safe to retry on timeout
  • Prefetching: Browsers may send GET requests before you click — if GET has side effects, unexpected things happen
Never use GET to modify data. GET /api/users/5/delete — browsers, crawlers, and prefetch mechanisms will call it freely. Google's crawler once deleted data from an app that did this.
Read full section →

Section 8HTTP Status Codes

Three-digit numbers: 1xx info, 2xx success, 3xx redirect, 4xx client error, 5xx server error.

Categories Overview

CategoryRangeMeaning
1xx100–199Informational — processing continues
2xx200–299Success — request accepted
3xx300–399Redirection — further action needed
4xx400–499Client Error — your fault
5xx500–599Server Error — server's fault

2xx & 3xx

CodeNameKey Detail
200OKThe most common status code
201CreatedNew resource; include Location header
204No ContentSuccess, no body (common for DELETE)
301Moved PermanentlyNew permanent URL; may change POST to GET
304Not ModifiedUse cached version (no body)
307Temporary RedirectPreserves method (POST stays POST)
Read full section →

4xx Client Errors

CodeNameKey Detail
400Bad RequestMalformed syntax or invalid input
401UnauthorizedNot authenticated (should be "Unauthenticated")
403ForbiddenAuthenticated but not authorized
404Not FoundResource doesn't exist
405Method Not AllowedWrong HTTP method for this URL
409ConflictConflicts with current resource state
422Unprocessable EntityValid syntax but invalid semantics
429Too Many RequestsRate limited; check Retry-After
401 vs 403: 401 = "I don't know who you are" (authenticate). 403 = "I know who you are, but no" (authorization). The name "Unauthorized" for 401 is misleading.
Read full section →

5xx Server Errors

CodeNameKey Detail
500Internal Server ErrorGeneric server-side failure
502Bad GatewayInvalid response from upstream
503Service UnavailableOverloaded or maintenance
504Gateway TimeoutUpstream didn't respond in time
Never expose stack traces in 5xx responses in production. Return a generic error and log details server-side. Stack traces reveal technology, file paths, and internal logic.
Read full section →

Section 9HTTP Headers

Metadata about the request or response: Name: value pairs, case-insensitive.

Common Request Headers

HeaderPurposeExample
HostWhich domain (required in HTTP/1.1)Host: example.com
AcceptPreferred content typesAccept: application/json
User-AgentIdentifies the clientMozilla/5.0 ...
AuthorizationCredentialsBearer eyJhbG...
CookieStored cookies sent backsession_id=abc123
Accept-EncodingCompression supportgzip, deflate, br
Read full section →

Common Response Headers

HeaderPurposeExample
Content-TypeBody formatapplication/json; charset=utf-8
Content-LengthBody size in bytes348
LocationRedirect or new resource URL/api/books/42
Set-CookieSets a cookie on the clientsession=abc; HttpOnly
Cache-ControlCaching directivesmax-age=3600
ServerServer softwarenginx/1.24
"Referer" is misspelled in the spec since 1996. The newer Referrer-Policy header uses the correct spelling, making the inconsistency permanent.
Read full section →

Section 10Content Negotiation

Client and server agree on the best format using Accept headers and quality values.

Accept Headers & Quality Values

HeaderNegotiatesExample
AcceptContent typetext/html, application/json;q=0.9
Accept-LanguageLanguageen-US, fr;q=0.5
Accept-EncodingCompressiongzip, br
── Request ───────────────────────────────────────── GET /api/books/42 HTTP/1.1 Host: example.com Accept: application/json;q=1.0, text/html;q=0.8 ── Response (server chooses JSON) ─────────────────── HTTP/1.1 200 OK Content-Type: application/json Vary: Accept {"id": 42, "title": "HTTP Guide"}
The Vary header tells caches: "this response depends on these request headers." Without Vary: Accept, a cache might serve a JSON response to a client that wants HTML.
Read full section →

Section 11Sending Data

Two ways: in the URL (query strings) or in the request body (form-encoded, multipart, JSON).

Query Strings vs Body Formats

FormatContent-TypeFiles?Nesting?Use Case
Query stringN/A (in URL)NoNoGET filtering, search, pagination
Form-encodedapplication/x-www-form-urlencodedNoNoHTML form submissions
Multipartmultipart/form-dataYesLimitedFile uploads
JSONapplication/jsonNoYesAPIs, fetch() calls
Query strings are visible everywhere: browser bar, server logs, Referer header, proxy logs. Never put secrets in query strings.
Read full section →

Section 12HTTP Caching

Store response copies to reuse without contacting the server. Reduces latency and server load.

Cache-Control Directives

DirectiveMeaning
publicAny cache (browser, CDN, proxy) can store it
privateOnly the browser can cache it (user-specific data)
no-cacheCache it, but revalidate before using
no-storeDo not cache at all (sensitive data)
max-age=NFresh for N seconds
immutableNever changes (versioned assets like app.v3.js)
"no-cache" does NOT mean "don't cache." It means "check with the server before using." For truly no caching, use no-store.
Read full section →

The 304 Not Modified Flow

Browser Server │ │ │ 1. First request │ │ GET /style.css ─────────────────────────▶ │ │ │ │ HTTP/1.1 200 OK │ │ ETag: "v42" │ │ Cache-Control: max-age=3600 │ │ [full CSS file] ◄─────────────────────── │ │ │ │ 2. After max-age expires (revalidation) │ │ GET /style.css │ │ If-None-Match: "v42" ───────────────────▶│ │ │ │ (Server checks: ETag still "v42"? Yes!) │ │ │ │ HTTP/1.1 304 Not Modified │ │ (no body — use cached version) ◄─────────│ │ │
ETag + If-None-Match is the modern validation mechanism. The server sends an ETag (content fingerprint), and the browser sends it back to ask "has this changed?" If not, 304 saves bandwidth.
Read full section →

Section 13Cookies & State

HTTP is stateless. Cookies bolt state onto a stateless protocol via Set-Cookie / Cookie headers.

Cookie Login Flow

Browser Server │ │ │ 1. Login request │ │ POST /login │ │ (username + password) ──────────────────▶ │ │ │ │ 2. Server creates a session │ │ HTTP/1.1 200 OK │ │ Set-Cookie: session_id=abc123; HttpOnly ◄──│ │ │ │ 3. Every subsequent request (automatic) │ │ GET /dashboard │ │ Cookie: session_id=abc123 ──────────────▶│ │ │ │ HTTP/1.1 200 OK │ │ [personalized dashboard] ◄──────────────│ │ │
Read full section →

Cookie Attributes & Sessions vs Tokens

AttributePurpose
HttpOnlyNot accessible via JavaScript (blocks XSS)
SecureOnly sent over HTTPS
SameSiteControls cross-site sending (Strict, Lax, None)
Max-AgeSeconds until expiration
DomainWhich domain(s) receive the cookie
ApproachState StoredBest For
Server sessionsOn the server (cookie holds session ID)Traditional web apps
Tokens (JWT)In the token itself (stateless)APIs, SPAs, mobile apps
Cookie security checklist: Always set HttpOnly, Secure, and SameSite=Lax (or Strict) on session cookies.
Read full section →

Section 14CORS

Cross-Origin Resource Sharing — how servers opt in to allowing requests from different origins.

Same-Origin Policy

Two URLs share the same origin only if scheme + host + port all match:

URL AURL BSame?Why
https://app.com/ahttps://app.com/bYesSame scheme, host, port
https://app.comhttp://app.comNoDifferent scheme
https://app.comhttps://api.app.comNoDifferent host (subdomain)
https://app.comhttps://app.com:8080NoDifferent port
Read full section →

Preflight Flow

Preflighted Request (PUT with JSON): Browser (app.com) Server (api.other.com) │ │ │ 1. Preflight (automatic) │ │ OPTIONS /data HTTP/1.1 │ │ Origin: https://app.com │ │ Access-Control-Request-Method: PUT │ │ Access-Control-Request-Headers: Content-Type│ │ ────────────────────────────────────────────▶ │ │ │ │ HTTP/1.1 204 No Content │ │ Access-Control-Allow-Origin: https://app.com│ │ Access-Control-Allow-Methods: GET, PUT, POST│ │ Access-Control-Allow-Headers: Content-Type │ │ ◄──────────────────────────────────────────── │ │ │ │ 2. Actual request (if preflight passes) │ │ PUT /data HTTP/1.1 │ │ Content-Type: application/json │ │ {"key": "value"} ─────────────────────────▶ │ │ │ │ HTTP/1.1 200 OK ◄──────────────────────────│ │ │
Simple requests (GET/HEAD/POST with safe headers) skip the preflight. Anything else (PUT, DELETE, custom headers, JSON Content-Type) triggers the OPTIONS preflight first.
Read full section →

Section 15HTTP Authentication

Challenge-response framework: 401 + WWW-Authenticate → client sends credentials.

Authentication Methods

MethodHow It WorksProsCons
Basic AuthBase64 user:pass in every requestSimple, universalEncoding, not encryption
Bearer / JWTToken in Authorization headerStateless, scalableToken management
API KeyKey in header or queryEasy to provision/revokeNo standard; visible in logs if in URL
Cookie SessionSession ID in cookieBrowser handles it, HttpOnlyServer-side state, CSRF risk
Basic Auth is encoding, not encryption. dXNlcjpwYXNzd29yZA== decodes to user:password. Anyone who intercepts the request can read credentials. Never use Basic Auth without HTTPS.
Read full section →

Sessions vs Tokens

AspectCookie SessionsToken-Based (JWT)
StateServer stores session dataToken contains all data
Sent howAutomatically (Cookie header)Manually (Authorization header)
Cross-domainComplex (CORS + SameSite)Easy (just include header)
RevocationEasy (delete server session)Hard (valid until expiry)
Best forTraditional web appsAPIs, SPAs, mobile, microservices
Read full section →

Section 16Security Headers

Response headers that instruct browsers to enable additional security protections.

Essential Security Headers

HeaderPurposeExample
Strict-Transport-SecurityForces HTTPSmax-age=31536000; includeSubDomains
Content-Security-PolicyControls resource loadingdefault-src 'self'
X-Content-Type-OptionsPrevents MIME sniffingnosniff
X-Frame-OptionsBlocks clickjackingDENY
Referrer-PolicyControls Referer headerstrict-origin-when-cross-origin
Permissions-PolicyControls browser featurescamera=(), microphone=()
# Nginx configuration add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "DENY" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
Test your headers at securityheaders.com. Adding these six headers typically brings you to an A grade.
Read full section →

Section 17HTTPS and TLS

HTTP + TLS = encryption, integrity, and authentication. Three guarantees for secure communication.

The TLS Handshake

Client Server │ │ │ 1. ClientHello │ │ "I support TLS 1.3, these ciphers..." ───▶│ │ │ │ 2. ServerHello + Certificate │ │ "Let's use TLS 1.3 with this cipher. │ │ Here's my certificate to prove I'm │ │ example.com" ◄────────────────────────│ │ │ │ 3. Client verifies certificate │ │ (CA signature, domain match, expiry) │ │ │ │ 4. Key Exchange (Diffie-Hellman) │ │ Both compute shared secret ─────────────▶│ │ │ │ 5. Encrypted connection established │ │ All HTTP traffic now encrypted ◄────────▶│ │ │
Read full section →

Certificates & Why HTTPS Everywhere

  • Let's Encrypt: Free, automated certificates. Made HTTPS accessible to everyone.
  • Certificate chain: Your cert → intermediate CA → root CA. Browsers trust a built-in list of root CAs.
  • Certificates expire (90 days for Let's Encrypt) — renewal is automated via ACME.

Why HTTPS Matters

  • Security: Prevents eavesdropping, tampering, impersonation
  • Privacy: ISPs can't see full URLs or content
  • Required: Service workers, geolocation, camera, HTTP/2 all need HTTPS
  • SEO: Google ranks HTTPS higher
  • Trust: Browsers show "Not Secure" for HTTP
HTTPS does not mean "the site is safe." It means the connection is encrypted and authenticated. A phishing site can have a valid TLS certificate. HTTPS secures the channel, not the content.
Read full section →

Section 18Observing HTTP

DevTools Network tab for browsers, curl -v for the command line.

Browser DevTools Tips

  • Filter by type: Click "Fetch/XHR" to see only API calls
  • Click any request to inspect headers, timing, and response body
  • Right-click → "Copy as curl" generates a complete curl command
  • Timing breakdown: DNS, TCP, TLS, TTFB, content download
  • Preserve log: Keep requests visible across navigations (essential for debugging redirects)
Read full section →

curl Walkthrough

FlagPurpose
-vVerbose — show full headers
-iInclude response headers
-IHEAD request (headers only)
-HAdd custom header
-dSend body data (implies POST)
-XSpecify HTTP method
-LFollow redirects
$ curl -v https://httpbin.org/get * Connected to httpbin.org port 443 * TLS handshake completed (TLS 1.3) > GET /get HTTP/2 ← Request line > Host: httpbin.org ← Required header > User-Agent: curl/8.4.0 ← curl identifies itself > Accept: */* ← Accept anything > < HTTP/2 200 ← Status < content-type: application/json ← JSON response < access-control-allow-origin: * ← CORS: allow all < { "headers": { "Host": "httpbin.org", "User-Agent": "curl/8.4.0" }, "url": "https://httpbin.org/get" }
"Copy as curl" in DevTools is one of the most useful debugging features. Right-click any request in the Network tab — you get a complete curl command ready to replay and tweak.
Read full section →

SummaryKey Takeaways

18 sections of HTTP fundamentals in one table.

HTTP at a Glance

ConceptKey Points
What is HTTPApplication-layer, client-server, stateless, request-response
Versions0.9 → 1.0 → 1.1 (keep-alive) → 2 (multiplexing) → 3 (QUIC)
Request-ResponseThree parts each: start line, headers, body
MethodsGET (read), POST (create), PUT (replace), PATCH (update), DELETE (remove)
Safety/IdempotencySafe = no side effects. Idempotent = repeatable. POST is neither.
Status Codes1xx info, 2xx success, 3xx redirect, 4xx client, 5xx server
HeadersRequest, response, representation, general. Host is required.
Content NegotiationAccept headers + quality values. Vary header for caching.
Sending DataQuery strings (GET), form-encoded, multipart (files), JSON (APIs)
CachingCache-Control, ETag, 304 Not Modified. no-cache ≠ don't cache.
CookiesSet-Cookie/Cookie for state. HttpOnly + Secure + SameSite.
CORSSame-Origin Policy. CORS headers let servers opt in to cross-origin.
AuthenticationBasic (encoding), Bearer/JWT (stateless), API keys, cookie sessions
Security HeadersHSTS, CSP, X-Content-Type-Options, X-Frame-Options
HTTPS/TLSEncryption + integrity + authentication. HTTPS ≠ safe site.
Observing HTTPDevTools Network tab + curl -v. "Copy as curl" bridges both.
Read the full HTTP Fundamentals overview →  |  Review Questions →