Foundational Concepts

1. The Internet vs the Web

The Internet is a global network of interconnected computer networks — the physical infrastructure of routers, cables, fiber optics, and communication protocols that allow computers to talk to each other. It has existed since the late 1960s (ARPANET).

The Web (World Wide Web) is just one application that runs on top of the Internet. Tim Berners-Lee invented it in 1989 by combining three technologies: HTTP (the protocol), HTML (the content), and URLs (the addresses).

Other applications that run on the Internet:

Application	Protocol	Purpose
Email	SMTP / IMAP / POP3	Sending and receiving messages
File Transfer	FTP / SFTP	Moving files between machines
Remote Shell	SSH	Secure command-line access to servers
Domain Resolution	DNS	Translating domain names to IP addresses
Streaming	RTSP / HLS	Audio/video delivery

2. The Network Stack: What HTTP Runs On

HTTP is an application-layer protocol. It doesn't deal with packets, routing, or reliable delivery — it delegates that to lower layers. Understanding where HTTP sits in the stack helps you debug network issues and understand performance.

The TCP/IP Model (4 Layers)

Key Protocols in the Stack

DNS (Domain Name System) — translates human-readable domain names (example.com) into IP addresses (93.184.216.34). This is the first thing that happens when you type a URL. Without DNS, you'd need to memorize IP addresses.

TCP (Transmission Control Protocol) — provides reliable, ordered delivery of data. Before any HTTP data flows, TCP establishes a connection with a three-way handshake:

IP (Internet Protocol) — handles addressing and routing. Every device on the Internet has an IP address. IPv4 addresses look like 192.168.1.1 (32-bit, ~4 billion addresses). IPv6 addresses look like 2001:0db8::1 (128-bit, effectively unlimited).

3. Client-Server Architecture

The client-server model is the fundamental architecture of the Web. The client initiates a request; the server processes it and sends a response. The server never initiates communication — it only responds.

This model has a critical implication: the server is passive. It sits and waits. It cannot push data to clients unless a client first establishes a connection. (Technologies like WebSockets upgrade this model, but the initial connection is always client-initiated.)

Why This Matters

• Polling vs Pushing: If the server has new data, it can't tell the client. The client must ask (poll). WebSockets and Server-Sent Events (SSE) are workarounds for this limitation.
• Statelessness: Each request is independent. The server doesn't inherently remember previous requests. State must be managed explicitly (cookies, sessions, databases).
• Scalability: Because the server is stateless, you can put multiple servers behind a load balancer and any server can handle any request.

4. What Happens When You Type a URL

This is the single most important mental model in the course. When you type a URL and press Enter, approximately 15 things happen in sequence. Understanding this flow connects every topic in this course.

These steps group into natural phases:

Phase	Steps	Where It Happens	Course Connection
Resolution	1–2	Client + DNS	URL Overview
Connection	3–4	Client ↔ Server	Section 2 (Network Stack)
Request	5–6	Client → Server	HTTP Overview
Processing	7–8	Server	Execution Models
Response	9–10	Server → Client	HTTP Overview
Rendering	11–15	Client (Browser)	Section 13 (Dev Models)

5. The Three Pillars of the Web

Tim Berners-Lee's 1989 invention combined three technologies that, together, create the Web:

Pillar	What It Does	Analogy	Learn More
HTTP	The protocol — how client and server communicate	The postal system (how mail gets delivered)	HTTP Overview
HTML	The content — what gets displayed	The letter itself (the message)	Section 10 below
URLs	The addresses — where things are	The mailing address (where to deliver)	URL Overview

Everything else — CSS, JavaScript, databases, frameworks, APIs — builds on top of these three. CSS styles the HTML. JavaScript adds interactivity. Databases store data. Frameworks organize code. But at the bottom, it's always HTTP carrying HTML to a URL.

6. The Five Pillars of Web Technology

Beyond the three core technologies, the full landscape of web development spans five broad pillars. Understanding where each topic fits helps you see the forest for the trees.

Pillar	What It Covers	Examples	Course Coverage
Architecture	How systems are structured and how they communicate	Client-server, REST, MVC, microservices, HTTP, TCP/IP	Primary focus
Coding	The languages and frameworks used to build applications	PHP, Node.js, Python, SQL, JavaScript, HTML	Primary focus
Hosting	Where and how applications are deployed and run	Apache, Nginx, Linux, Docker, cloud (AWS/GCP), DNS	Primary focus
Design	How the user interface looks and behaves	CSS, responsive design, UX patterns, accessibility	Mentioned, not deep
Content/Visuals	The actual content, media, and visual assets	Images, video, typography, data visualization, copy	Mentioned, not deep

7. Three Participant Groups

Web technology doesn't exist in a vacuum. Three groups of people (plus a fourth) shape every technology decision:

Group	Cares About	Common Conflict
Developers	Clean code, modern tools, developer experience, interesting problems	May over-engineer or choose tools for resume appeal rather than user benefit
Business / IT	Cost, time-to-market, reliability, compliance, ROI	May cut corners, resist upgrades, or choose "safe" legacy technologies
Users	Speed, ease of use, accessibility, privacy, getting the task done	Rarely consulted directly; their needs are often assumed rather than measured
Government	Privacy regulations, accessibility mandates, data protection	GDPR, ADA/WCAG compliance, CCPA — adds requirements that all three groups must address

Technology choices are never purely technical. A developer might want React, the business might want WordPress, and the user just wants the page to load fast. Understanding these tensions helps you make better decisions — and argue for the right ones.

8. UX vs DX: The Eternal Tension

DX (Developer Experience) is what makes the developer's job easier: powerful frameworks, hot module reloading, type systems, component libraries, build tools. UX (User Experience) is what makes the user's experience better: fast page loads, accessibility, working without JavaScript, small download sizes.

These two goals frequently conflict:

DX Choice	User Impact
2 MB JavaScript bundle for a blog	Slow load, broken without JS, drains mobile battery
Client-side rendering for static content	Blank page until JS loads, poor SEO, fails on slow networks
Heavy build pipeline (webpack, babel, etc.)	No direct impact, but complexity breeds bugs
CSS-in-JS libraries	Larger bundle, slower rendering, flash of unstyled content

9. Client-Server Trade-offs

One of the most important architectural decisions in web development is where logic runs: on the client (browser) or on the server. This is the "thick client vs thin client" spectrum.

Aspect	Thick Client (More in Browser)	Thin Client (More on Server)
Examples	React SPA, Gmail, Google Docs	Wikipedia, Craigslist, traditional forms
Initial load	Slow (large JS bundle must download and execute)	Fast (server sends ready-to-render HTML)
Navigation	Fast after load (no page reloads)	Each page requires a server round-trip
Works without JS	No — blank page without JavaScript	Yes — HTML works in any browser
SEO	Difficult (content generated by JS)	Easy (content in HTML from server)
Server cost	Lower (client does rendering)	Higher (server renders every page)
Security	Business logic exposed in client JS	Business logic stays on server
Complexity	High (state management, routing, build tools)	Low (request → process → respond)

The Security Boundary

The most important line in web architecture is the trust boundary between client and server:

• The client is untrusted. Users can modify any HTML, CSS, or JavaScript. Browser DevTools make this trivial.
• The network is hostile. Without HTTPS, anyone can read or modify data in transit.
• The server is where truth lives. All validation, authorization, and business logic must run on the server.

Where to validate: Always on the server. Optionally also on the client for UX (instant feedback), but never only on the client.

10. HTML Fundamentals and Browser Forgiveness

HTML (HyperText Markup Language) is the content layer of the Web. It defines the structure and meaning of web content. Here's the minimal correct HTML5 document:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Page Title</title>
</head>
<body>
    <h1>Hello, World!</h1>
    <p>This is a valid HTML5 document.</p>
</body>
</html>

Live demo: /basics/hellohtml5.html — A simple HTML5 page with headings, paragraphs, and an image.

HTML vs XHTML: The Strictness Spectrum

In the early 2000s, the W3C tried to make HTML stricter by reformulating it as XML (XHTML). The key differences:

Feature	HTML5	XHTML
Tag case	<DIV> and <div> are the same	Must be lowercase: <div>
Closing tags	<br>, <img ...> (optional close)	Must self-close: <br />, <img ... />
Attributes	checked, disabled (boolean OK)	Must have values: checked="checked"
Error handling	Browser guesses and recovers	Parser stops on first error (yellow screen of death)

Live demos:

• /basics/helloxhtml5.html — XHTML served as HTML (browser is forgiving)
• /basics/helloxhtml5.xml — XHTML served as XML (browser enforces strict parsing)

Browser Error Tolerance

One of the most remarkable features of HTML is browser forgiveness. Browsers will render almost anything, no matter how malformed:

Live demo: /basics/malformedhtml.html — Missing tags, mismatched case, unclosed elements, non-standard tags — the browser still renders it.

11. Forms: How Data Gets to the Server

HTML forms are the original mechanism for sending data from the client to the server. Before fetch(), before XMLHttpRequest, before any JavaScript at all — forms were the only way users could send data.

GET Forms: Data in the URL

When a form uses method="GET", the form data is appended to the URL as query parameters:

<form action="/search" method="GET">
    <input type="text" name="q" value="javascript">
    <button type="submit">Search</button>
</form>

<!-- Submitting navigates to: /search?q=javascript -->

Live demo: /basics/formget.html — A form that submits data as query parameters.

POST Forms: Data in the Body

When a form uses method="POST", the form data is sent in the HTTP request body, not the URL:

<form action="/signup" method="POST">
    <input type="text" name="firstName">
    <input type="text" name="lastName">
    <select name="size">
        <option value="small">Small</option>
        <option value="medium">Medium</option>
        <option value="large">Large</option>
    </select>
    <button type="submit">Submit</button>
</form>

Live demo: /basics/formpost.html — A form that submits data in the request body.

Common Form Controls

Control	HTML	Purpose
Text input	<input type="text">	Single-line text entry
Password	<input type="password">	Masked text entry (but still plaintext in the request!)
Hidden	<input type="hidden">	Data sent with form but not displayed (but visible in source!)
Dropdown	<select>	Choose from predefined options
Textarea	<textarea>	Multi-line text entry
Checkbox	<input type="checkbox">	Boolean toggle (only sent when checked)

12. Client-Side Security Is an Illusion

This section demonstrates that every client-side "security" measure is trivially bypassable. Open your browser's DevTools (F12) and try it yourself.

Password Fields in GET Requests

A password field (<input type="password">) hides the characters on screen, but if the form uses GET, the password appears in plain text in:

• The URL bar
• Browser history
• Server access logs
• The HTTP Referer header when you navigate away

Hidden Fields Are Not Hidden

The <input type="hidden"> element is invisible on the page, but:

• Visible in "View Source"
• Visible and editable in DevTools
• Sent in the HTTP request like any other field

Client-Side Restrictions Are Decorative

maxlength="5", readonly, disabled — all trivially removed via DevTools. These attributes are UX conveniences, not security measures.

Live demo: /basics/formsecurity.html — A form with password fields, hidden fields, maxlength, and readonly. Open DevTools and try modifying everything.

Data Collection Zones

Data on the web exists in four zones, each with different security properties:

Zone	Who Controls It	Security Level
Client (browser)	The user (and any extensions/scripts)	Zero trust — user can modify anything
Transit (network)	ISPs, routers, proxies	HTTPS encrypts; HTTP is plaintext
Server	You (the developer/operator)	Trusted — this is where validation lives
Third-party (external scripts, CDNs)	Someone else	You're trusting their code in your page

Client-Side Storage Is Readable by Any Script

localStorage and sessionStorage let you store data in the browser, but any JavaScript on the page — including third-party scripts — can read it all:

Live demos:

• /basics/storage1.html — Save a "secret message" to localStorage or sessionStorage
• /basics/storage2.html — Navigate here and see your secret is still accessible. Notice the "harmless" third-party script that reads everything.

The "Harmless" Third-Party Script

The storage2.html page includes an external JavaScript file. That script iterates through all localStorage and sessionStorage keys, collects every value, and logs them. In a real attack, it would fetch() them to a remote server. This is how third-party scripts exfiltrate data — and you invited them onto your page.

13. Development Models: Where Does Rendering Happen?

The biggest architectural decision in web development: who builds the HTML that the user sees?

Server-Side Rendering (SSR)

The server generates complete HTML for every request. The browser receives a finished page and just displays it.

Client-Side Rendering (CSR)

The server sends a minimal HTML shell plus a large JavaScript bundle. The JavaScript fetches data via API and builds the page in the browser.

Hybrid / Progressive Enhancement

The server renders working HTML. JavaScript enhances the experience for browsers that support it. The page works without JS but is better with it.

Aspect	SSR	CSR	Hybrid
First page load	Fast (HTML ready)	Slow (JS must load + execute + fetch)	Fast (HTML ready, JS enhances)
Subsequent navigation	Slow (full page reload)	Fast (client-side routing)	Can be fast (progressive loading)
SEO	Excellent	Poor (without SSR pre-rendering)	Excellent
Works without JS	Yes	No	Yes (degraded gracefully)
Server load	Higher (renders every page)	Lower (serves static files + API)	Moderate
Complexity	Low	High (state management, routing, build)	Moderate

Toolbox Overflow

The modern web development ecosystem has an overwhelming number of tools, frameworks, and libraries. React, Vue, Angular, Svelte, Next.js, Nuxt, Astro, SvelteKit, Remix, Gatsby — the list grows yearly. This creates decision paralysis and a constant churn of "the new hotness."

The antidote is understanding what problem each tool solves and whether you actually have that problem. A blog doesn't need React. A dashboard might. A static marketing site doesn't need a build pipeline. A web application probably does.

Maturity-Safety Matrix

When evaluating technologies, consider two axes:

• Maturity: How long has it been used in production? How stable is the API? How large is the community?
• Safety: What's the blast radius if it fails? How well understood are the security implications?

Mature, safe technologies (HTML, CSS, server-rendered pages) are boring but reliable. Immature, risky technologies (the latest JS framework) are exciting but may not survive. For production systems, boring is a feature.

14. Summary

Concept	Key Takeaway
Internet vs Web	The Internet is infrastructure (cables, routers, protocols). The Web is one application on it (HTTP + HTML + URLs). Email, FTP, SSH are other Internet applications.
Network Stack	HTTP sits at the application layer, above TCP (reliable delivery), IP (routing), and physical links. DNS translates domain names to IP addresses.
Client-Server	Client asks, server answers. The server never initiates. Each request is independent (stateless). This model enables scalability.
Typing a URL	15 steps from URL parsing to pixels on screen: DNS, TCP, TLS, HTTP request, server processing, HTTP response, HTML parsing, CSS, JS, rendering.
Three Pillars	HTTP (protocol), HTML (content), URLs (addresses) — everything else builds on these three.
Five Pillars	Architecture, Coding, Hosting (this course), plus Design and Content/Visuals (CSE 134B).
Participant Groups	Developers, Business/IT, Users, and Government all shape technology decisions with different priorities.
UX vs DX	Developer convenience and user experience often conflict. When they do, UX should win. Users didn't choose your framework.
Client-Server Trade-offs	Thick client (SPA) vs thin client (server-rendered). Always validate on the server. The client is untrusted territory.
HTML Fundamentals	HTML5 is forgiving; XHTML is strict. Browsers recover from errors gracefully. This tolerance is why the Web grew so fast.
Forms	GET puts data in the URL; POST puts data in the body. Forms work without JavaScript. They're the original data submission mechanism.
Client-Side Security	Hidden fields, maxlength, readonly, password masking — all trivially bypassable. Never trust the client. Validate everything on the server.
Development Models	SSR (server builds HTML), CSR (JS builds HTML), Hybrid (server + progressive enhancement). This course focuses on SSR.

---

Back to Home | URL Overview | HTTP Overview | Web Servers Overview | REST Overview