Module 0

HTTP & Web Foundations

How the Web Works • Requests & Responses • Status Codes

🌐 How the Web Works

Before writing JavaScript, you need to understand the protocol that powers the web. Every time you visit a website, your browser speaks HTTP — a simple language of requests and responses.

This module covers the fundamentals of HTTP: how clients talk to servers, what happens inside each message, and the status codes and headers that control everything from caching to authentication.

🎯 By the end of this module, you will:

  • Understand the client-server model and how HTTP requests flow
  • Read and interpret HTTP messages (start line, headers, body)
  • Use status codes correctly (2xx, 3xx, 4xx, 5xx)
  • Know key HTTP headers and their purpose
  • See how JavaScript runs in browsers and on the server (Node.js)
🌐HTTP Protocol
  • Client-server architecture
  • Request/response cycle
  • Status codes & headers
⚡JavaScript Core
  • Functions, objects & arrays
  • Async: Promises & async/await
  • Modern ES6+ syntax
🖥️Browser APIs
  • DOM manipulation
  • Events & event handling
  • Fetch API & AJAX
🚀Node.js
  • Server-side JavaScript
  • File system & modules
  • Building APIs

📚 Course Flow

HTTP Basics → JS Core → Browser → Node.js

🔀 HTTP Topology: The Big Picture

Below is a live topology of how HTTP works. Multiple clients (browser, mobile, CLI) send requests to the server, and the server can call external APIs too. Click Play to watch the flow.

👥 Client & Server: How They Connect

Every HTTP request involves a client and a server.

🔄 Roles per request

A client starts a request; a server answers. In chains (your server → external API) the roles switch per hop.

🔌 Why ports?

One IP, many apps. The OS delivers packets to the process bound to the destination port (e.g. 80, 443, 3000).

🌍 DNS → IP

Resolve example.com to an IP address (cached by TTL). CDNs often answer with a nearby edge server.

🤝 Connect, then HTTP

TCP 3‑way handshake → TLS (for HTTPS) → send request line + headers → receive response.

🔌 Deep Dive: Ports & Sockets

🔌 Overview

  • Well‑known vs dynamic: 80/443 (HTTP/HTTPS), 22 (SSH), 25 (SMTP), 5432 (Postgres). Clients pick an ephemeral source port per connection.
  • One IP, many services: Ports let multiple protocols coexist (web, SSH, mail) on a single interface.
  • 4‑tuple identity: A TCP connection = (srcIP:srcPort ⇄ dstIP:dstPort). This uniquely identifies the conversation.

🔄 Lifecycle

  • bind: Process requests a local ip:port.
  • listen: Kernel queues SYNs on the listening socket.
  • accept: Each accepted connection spawns a new socket (same local port, new remote 4‑tuple).
  • TIME_WAIT: After close, socket stays around briefly to catch late packets.

🔒 Security

  • Firewalls: Rules frequently target destination ports (e.g. allow 443, deny 23).
  • Least privilege: Services under 1024 often started via a helper (systemd socket activation, reverse proxy).
  • Scanning: Port scans reveal attack surface; rate limiting + stealth ports reduce noise.

🌐 Virtual & Proxy Layers

  • Virtual hosting: Same 443 handles many domains via HTTP Host + TLS SNI.
  • Reverse proxy: Edge (443) fans into internal ports (e.g. 3000 API, 3100 auth, 3200 assets).
  • Containers: Host port 8080 → container 127.0.0.1:80; kube‑services abstract pods behind stable ports.

🎲 Ephemeral Ports

  • Range: Often 49152–65535 (Linux configurable via /proc/sys/net/ipv4/ip_local_port_range).
  • Selection: Kernel chooses a free port; randomness defends against spoofing.
  • Observation: Seeing many adjacent source ports can indicate sequential allocation (old OS behavior).
Terminal
lsof -iTCP -sTCP:LISTEN -n | grep -E ':(80|443|3000)'  # Show listening sockets
ss -tulpn                                                   # Modern socket summary
netstat -an | grep 443                                      # Legacy netstat usage
iptables -L -n | grep 443                                   # Firewall rule referencing a port
sysctl net.ipv4.ip_local_port_range                         # Ephemeral range
🌍 Deep Dive: DNS Resolution

Core Flow

  1. App asks OS stub resolver.
  2. Stub queries recursive (e.g. 1.1.1.1).
  3. Recursive walks: root → TLD (.com) → authoritative (zone NS).
  4. Answer cached at each layer until TTL expires.

📋 Record Types

  • A / AAAA: IPv4 / IPv6 address.
  • CNAME: Alias chain (never with other data at same node).
  • MX: Mail exchangers (with priority numbers).
  • TXT: Arbitrary text (SPF, domain verification).
  • SRV: Service discovery (host + port + priority/weight).
  • CAA: Restrict which CAs can issue certificates.
  • NS: Delegation points for subzones.

⏱️ Caching & TTL

  • Layered: Browser → OS → recursive → authoritative.
  • Negative: NXDOMAIN cached per SOA MINIMUM or explicit TTL.
  • Tuning: Low TTL for active failover; higher TTL for stability/perf.

🗺️ Geo & CDN

  • Anycast resolvers: One IP, many edge POPs.
  • Latency steering: Different A answers per region.
  • Health checks: Remove bad endpoints before clients see them.

🔐 Security

  • DNSSEC: Signatures prove authenticity (no privacy).
  • DoT / DoH: Encrypt resolver channel; hides queries from local network.
  • Mitigations: Random source port + query ID thwart basic spoofing.
Terminal
dig +trace example.com                 # Full resolution path
dig A example.com @1.1.1.1             # Force specific resolver
dig CAA example.com                    # Certificate authority authorization
dig _sip._tcp.example.com SRV          # Service record lookup
drill -S example.com                   # DNSSEC validation with drill
nslookup -type=MX example.com
🤝 Deep Dive: Connect, then HTTP

Handshake Stack

  1. TCP: SYN → SYN‑ACK → ACK establishes reliability metadata (seq/ack windows).
  2. TLS: ClientHello (SNI, ALPN, cipher suites) → ServerHello (chosen params, cert) → key exchange → Finished.
  3. HTTP framing: Request line + headers (or HTTP/2 binary frames / HTTP/3 QUIC frames).

1️⃣ HTTP/1.1

  • Textual, one request at a time per connection (pipeline risks HOL blocking).
  • Upgrade: Connection: keep-alive reduces extra handshakes.
  • Head-of-line: Large response delays following requests.

2️⃣ HTTP/2

  • Binary frames over one TCP connection: multiplex streams.
  • Header compression (HPACK) saves bytes.
  • Still vulnerable to TCP-level HOL blocking if packet loss occurs.

3️⃣ HTTP/3 (QUIC)

  • Runs atop UDP with built-in encryption + congestion control.
  • Stream independence removes TCP HOL blocking latency waterfalls.
  • Connection migration: resume if client IP changes (mobile network switch).

🔐 TLS 1.3 & Performance

  • Reduced round‑trips vs TLS 1.2; faster first byte.
  • 0‑RTT resumption: can send early data (idempotent only!).
  • Session tickets rotate keys; too many cause memory pressure.

🔗 Connection Strategies

  • Pooling: Limit concurrent connections per origin (browsers enforce caps).
  • Coalescing: HTTP/2 reuse across origins sharing certificate SANs.
  • Retry logic: Exponential backoff; beware retry storms on partial outages.

📊 Observability

  • TTFB: handshake + server generation time until first byte.
  • Waterfall charts: Reveal parallelization and blocking gaps.
  • Metrics: handshake duration, TLS reuse %, connection reuse %, 0‑RTT hit rate.
Terminal
curl -v https://example.com/product/42        # Show TLS + request/response
curl --http2 -I https://example.com           # Force HTTP/2, headers only
curl --http3 -I https://example.com           # Force HTTP/3 (if supported)
openssl s_client -connect example.com:443 -alpn h2,http/1.1  # ALPN negotiation
tcpdump -nn 'port 443'                        # Inspect SYN/SYN-ACK/ACK
traceroute example.com                        # Path latency context
Advanced: routing & sockets

🔀 Reverse proxy routing

443 (Nginx) can route api.example.com → localhost:8000, www.example.com → localhost:3000, assets → localhost:9000.

🔌 Ephemeral client ports

Each connection is a 4‑tuple (clientIP:clientPort ⇄ serverIP:serverPort), e.g. 198.51.100.24:53214 ⇄ 203.0.113.10:443.

🌍 Anycast/CDN

One advertised IP maps to multiple edges; DNS and BGP steer you to a close POP.

💬 Communication Examples

GET ↗ Outgoing

GET Request

A simple GET request to fetch a list of users. The client specifies it accepts JSON.

GET /api/users HTTP/1.1
Host: example.com
Accept: application/json
POST ↗ Outgoing

POST Request

A POST request to create a new user. The body contains JSON data.

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{"name":"Mehdi","role":"student"}
200 OK ↙ Incoming

Server Response

A successful response with caching headers, compression, and an ETag for revalidation.

HTTP/1.1 200 OK
Date: Thu, 06 Nov 2025 10:11:12 GMT
Content-Type: application/json; charset=utf-8
Cache-Control: max-age=60, public
ETag: "users:v1:af31b2"
Content-Encoding: br

[{"id":1,"name":"Mehdi"},{"id":2,"name":"Ada"}]
Start line Headers Blank line Body

Reading the response without the body: Status + headers already tell you success, cacheability, compression, and revalidation strategy (ETag). Monitoring tools often ignore the body entirely.

Beyond GET & POST: HTTP defines more methods — PUT (replace), PATCH (partial update), DELETE (remove). We'll use them all when building REST APIs in Module 5.

📨 More Message Examples (HTML response, GET with query params)

GET with query parameters

GET /api/users?page=1 HTTP/1.1
Host: example.com
Accept: application/json

<!-- GET requests should not include a body -->

HTML Response

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=120, public

<!doctype html>
<html>
  <head><title>Example</title></head>
  <body>
    <h1>Hello from the web server</h1>
  </body>
</html>

Legend: start line • headers • blank line • body. Tip: GET requests do not include a body; use query parameters or POST for complex searches.

📨 Anatomy of HTTP Messages

A message = start line + headers + optional body. Each part has distinct semantics.

Start Line
GET /api/users HTTP/1.1
Method + Path + Version (request) or Version + Status + Reason (response)
Headers
Host: example.com
Accept: application/json
Authorization: Bearer ...
Key: Value pairs. Control caching, auth, content type, routing.
Empty Line
↵
CRLF separator between headers and body. Required.
Body
{"name":"Mehdi","role":"student"}
Optional. Format defined by Content-Type. Can be JSON, HTML, binary, etc.

Intermediaries (proxies, load balancers) often ignore the body for routing decisions. They rely on headers for caching, retries, and compression.

📊 Status Codes: Semantics & Strategy

Status codes drive caching, retries, SEO, monitoring and auth flows before any body is read. Use precise codes consistently.

Range Meaning Common Codes
2xx Success 200 OK · 201 Created · 204 No Content · 206 Partial
3xx Redirect 301 Permanent · 302 Temp · 303 See Other · 304 Not Modified · 307/308 Preserve method
4xx Client Error 400 Bad Request · 401 Unauthorized · 403 Forbidden · 404 Not Found · 409 Conflict · 422 Unprocessable · 429 Too Many
5xx Server Error 500 Internal · 502 Bad Gateway · 503 Unavailable · 504 Timeout

Decision tree: (1) Did the request succeed? → 2xx. (2) If not, is the fault on the client (4xx) or server (5xx)? (3) Pick the most specific code — never tunnel errors through 200.

📋 Status Code Patterns (Design Guide)

🔐 Auth vs Authorization

401 = "who are you?" · 403 = "I know you, but no"

  • 401 No/expired credentials → include WWW-Authenticate.
  • 403 Credentials valid but action forbidden (scope/role).
  • Rule: Can supplying new credentials help? If yes → 401, else 403.

✓ Validation & Semantics

400 = malformed · 422 = well-formed but invalid · 409 = conflict

  • 400 Malformed (parse/type error).
  • 422 Well-formed but domain rule failed.
  • 409 Version / uniqueness / state conflict.
  • 410 Resource intentionally removed (stop retrying).

💾 Caching & Conditionals

200 with ETag → 304 on revalidation

  • 200 Fresh; send ETag/Cache-Control.
  • 304 Validator matched (If-None-Match/If-Modified-Since).
  • Rule: Always emit a strong validator for cacheable GETs.

🔄 Retries & Resilience

502/503/504 are retryable · 500 may not be · 429 = back off

  • 502 Upstream error (dependency failed).
  • 503 Temporary overload / maintenance (add Retry-After).
  • 504 Upstream timeout.
  • Retry only idempotent methods (GET, HEAD, OPTIONS, safe DELETE, some PUT).

⏱️ Rate Limiting

  • 429 Too Many Requests (quota window exceeded).
  • Return: Retry-After, X-RateLimit-Remaining, X-RateLimit-Reset.
  • Rule: Use 429 (not 403) for transient quota exhaustion.
HTTP/2 429
Retry-After: 5
X-RateLimit-Remaining: 0
{"error":"rate_limit","retry_in":5}

📦 Bulk / Partial

  • 207 Multi-Status (mixed results) OR
  • 200 with per-item status objects.
  • Prefer 200 + array unless spec needs 207.
{"results":[
  {"id":1,"status":201},
  {"id":2,"status":409,"error":"duplicate"}
]}

📥 Ranges / Downloads

  • 206 Partial Content (serve byte range).
  • 416 Invalid range request.
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/4096

🔁 Idempotent Mutations

  • PUT replace → 200 (return body) or 204 (no body).
  • PATCH partial update → 200/204; use 409 on version mismatch.
  • DELETE existing or already deleted → often always 204 to be idempotent.

📋 Error Envelope

  • Shape: { error, message?, details?, trace_id? }.
  • No stack traces in prod; supply correlation id.
  • Never use 200 with an error wrapper.
{"error":"conflict","message":"Version mismatch","expected_version":12}

Decision Cheatsheet

  • Malformed JSON: 400
  • Business rule fail: 422
  • Concurrent update: 409
  • Missing auth: 401
  • Not allowed: 403
  • Over capacity: 503 + Retry-After
  • Rate limited: 429
  • Removed resource: 410

📋 Headers & Content Types

Headers = metadata. Start line + headers often decide caching, routing, and auth before the body is read.

🤝 Negotiation

Accept, Content-Type, Accept-Language

Client and server agree on format, language, and encoding of the response.

💾 Caching

Cache-Control, ETag, Last-Modified, Age

Controls how long responses are stored and when to revalidate with the server.

🔐 Auth

Authorization, WWW-Authenticate

Carries credentials (tokens, API keys) so the server knows who you are.

🍪 Session

Cookie, Set-Cookie

Small data stored by the browser and sent automatically with every request to that domain.

📦 Compression

Accept-Encoding, Content-Encoding

Reduces payload size over the wire. Server picks the best algorithm the client supports.

🛡️ Safety

Content-Security-Policy, HSTS, X-Frame-Options

Prevents XSS, clickjacking, and forces HTTPS. Set by the server in response headers.

🧭 Routing

Host, X-Forwarded-*, Traceparent

Determines which backend handles the request. Proxies add forwarding headers for origin info.

✂️ Request Shaping

Range, If-None-Match, If-Modified-Since

Conditional requests and partial content. Avoid re-downloading unchanged resources.

📄 Deep Dive: Content Types & Representation

📤 Common Responses

HTML · JSON · XML · Images · PDF

📥 Common Requests

JSON · Form URL Encoded · Multipart · Binary

🔢 Versioning

  • Media type version (vnd.*+json)
  • Path / query

🗜️ Compression

  • Textual formats compress well (gzip, brotli).
  • Pre-compress static assets for best performance.

Correctness: Wrong Content-Type breaks caches, confuses parsers, and can cause security issues. Be explicit; avoid guessing.

⚡ JavaScript Overview

⚙️ How JavaScript Works

📝
Your Code
.js files
→
🔧
JS Engine
V8, SpiderMonkey
→
⚡
Execution
Machine code
Single-Threaded
One task at a time
Event Loop
Handles async operations
ECMAScript
Language standard
Non-Blocking
Async I/O operations

JS engines (like V8, SpiderMonkey) implement the ECMAScript standard. JavaScript is single‑threaded with an event loop; asynchronous work uses callbacks, promises, and async/await.

Core Concepts at a Glance

📦

Types & Variables

Primitives, type coercion, let/const, functions & arrow functions

stringnumberboolean() =>
🏗️

Objects & Context

Object literals, prototypes, this binding, classes & constructor patterns

thisbindclassnew
📊

Arrays & Iteration

Functional array methods, higher-order functions, transformations & reductions

mapfilterreducesort
⚡

Errors & Async

Exception handling, promises, async/await, error propagation patterns

try/catchPromiseasyncawait

Ready to learn JavaScript? Continue to Module 1: JS Language Core for variables, functions, objects, and more.

🚀 Node.js Overview

Node.js runs JavaScript on the server using Chrome's V8 engine plus system bindings for files, network, and OS access.

🚀 Node.js Architecture

📝 Your JavaScript Code
↓
🔧 Node.js APIs
fs, http, path, crypto…
↓
V8 Engine
JS execution
libuv
Async I/O
↓
💻 Operating System
Files, Network, Processes
Common Use Cases
🌐 REST APIs ⚡ Real-time apps 💻 CLI tools 🔗 Microservices

Node.js runs JavaScript on the server using the V8 engine plus system bindings for files, network, and more. It's great for I/O‑heavy apps where non-blocking asynchronous processing shines.

We'll explore Node.js in depth in Module 4: Node.js Fundamentals.

📝 Summary

🌐 HTTP Protocol

A request/response protocol. Clients send requests, servers answer. Stateless by default.

🖥️ Client & Server

Client initiates requests, server listens and responds. Proxies, CDNs, and load balancers sit in between.

📨 Messages

Start line + headers + optional body. Headers control everything before the body is read.

📊 Status Codes

2xx success, 3xx redirect, 4xx client error, 5xx server error. Be specific, never tunnel errors through 200.

📋 Headers

Metadata key-value pairs. Control content negotiation, caching, auth, security, and compression.

⚡ JavaScript

Single-threaded with event loop. Runs in browsers (DOM) and on servers (Node.js).

🟢 Node.js

JavaScript runtime built on V8 + libuv. Non-blocking I/O, npm ecosystem, ideal for network services.

1
Next Module 1 / 7

Module 1: JavaScript Language Core

Variables, types, functions, arrow functions, callbacks, objects, and the this keyword.

var / let / const functions arrow => callbacks this objects
→