Class 2 · 60 minutes
HTTP, web servers, and your very first HTML file.
Last class you learned who talks on the web — clients ask, servers answer. Today you learn how they talk, meet the software that does the answering, set up your own toolkit, and — before this hour ends — write a file the browser can actually open.
By the end of this session there will be a folder on your computer, created by you, containing a real HTML file, written by you, open in your browser. Not an example on the projector — yours. Everything else today exists to make that moment make sense.
Idea one
HTTP: the language clients and servers agreed to speak.
Last class ended with a browser asking and a server answering. But asking in what language? Two machines built by different companies, on different continents, running different software — they can only converse because both sides follow one shared set of rules for how an ask and an answer must be phrased. That rulebook is HTTP.
A protocol is just an agreed procedure — the way "hello, may I speak to…" starts a phone call, or the way a bank challan must be filled in the bank's format or the clerk hands it back. HTTP is that, for the web: a fixed format for requests going one way and responses coming back the other. Because every browser and every web server honours the same format, any client can talk to any server, anywhere, first try — no introductions needed.
The prefix literally announces "this conversation will follow HTTP rules." And the padlock you toured in Chrome last class? That's HTTPS — the same conversation with one upgrade: everything is encrypted in transit, so anyone tapping the wire sees scrambled noise instead of your password. Same language, sealed envelope. Nearly every serious site today insists on it.
Q. Define HTTP. [2M]
Ans. — the four-move shape, then deeper than two marks demand ↓
HTTP (HyperText Transfer Protocol) is the standard protocol used for communication between web browsers (clients) and web servers.✓ ½
It defines the rules for how a client sends a request for a resource such as a web page, and how the server returns a response containing that resource.✓ ½
It follows a request–response model…✓ ½
…and is a stateless protocol — each request is treated independently, with no memory of previous requests.✓ ½
Beyond the marks — why “stateless” is worth memorising. Statelessness is not a flaw; it is why the web scales — a server that remembers nobody can serve anybody next, millions per minute. Everything that feels like memory (staying logged in, a cart that persists) is bolted on top with cookies and sessions — which is exactly where Unit 4 picks up the story.✚ depth
definition + one property = full 2 marks ✓ — the diagram and depth are course habit, not exam padding
Notice the shape of that model answer: expand the abbreviation, state what it connects, name the model, add one property. Four moves, four sentences at most. A 2-mark question pays for precision, not length — an examiner reading "HTTP is used for websites and the internet and browsing" finds nothing to award marks to. Practise compressing every definition this semester into that four-move shape and 2-mark questions become free marks.
ADD-ON · THE MAN WHO INVENTED ALL OF THIS — IN ONE YEAR
Tim Berners-Lee, 1989–91: three inventions, one working web.
The web was not assembled from pieces by many companies over decades. One physicist at CERN, trying to help scientists share documents, designed all three missing pieces together — because each is useless without the other two. You've just met one of them formally; here is the full set.
HTML
HYPERTEXT MARKUP LANGUAGEThe language for writing the documents themselves — pages whose text can carry links to other pages. Without it, there is nothing to share.
ITS JOB: the CARGO — what a page ISHTTP
HYPERTEXT TRANSFER PROTOCOLThe agreed rules for moving those documents between any client and any server — the request–response conversation you just defined for 2 marks.
ITS JOB: the DELIVERY — how a page MOVESURL
UNIFORM RESOURCE LOCATORThe addressing scheme — one unambiguous name for every document on Earth, so a request can say exactly which page it wants. It's what you type in the address bar.
ITS JOB: the ADDRESS — where a page LIVESOne-line exam answer worth memorising: "Tim Berners-Lee invented the World Wide Web at CERN (1989–91) by creating its three core technologies: HTML for writing hypertext documents, HTTP for transferring them, and the URL for addressing them." Note the web ≠ the internet — the internet (Class 1) is the road network; the web is one service running on it, the way postal mail and phone calls share the same roads.
His trio is literally this course's map: HTML is Classes 3–8 — you're writing it already; URLs you use every time you type an address, and their anatomy returns with forms and servers; HTTP came today and runs beneath everything from here to Unit 5. Three inventions, one semester.
Idea two
The surprise inside HTTP: it has no memory.
Here's the property that catches everyone off guard — and that word from the exam answer: HTTP is stateless. The server treats every single request as if it has never seen you before. Even the request you sent two seconds ago? Forgotten. Compare two conversations you already know:
"The usual" works on anna because he carries state — the running memory of who you are and what happened before. An HTTP server carries none. Request 2 arrives as a complete stranger's request, even though it came from the same browser, on the same laptop, in the same second-long visit.
If HTTP forgets you between requests, how does any site keep you logged in from one page to the next? Short answer: it can't — not with HTTP alone. Sites bolt memory on top, by handing your browser a token it re-presents with every request, like a canteen coupon anna stamps instead of remembering your face. When that token expires or gets lost — you're suddenly "logged out." The site didn't forget you; it never remembered you. The coupon ran out.
Because forgetting is what lets the web scale. If a server had to hold a running conversation-memory for every visitor, a site with ten million visitors would drown in bookkeeping — and no two servers could share the load, because only one of them "knows" you. Stateless servers can answer any request from anyone, in any order, on any machine in the fleet. The web handles billions of users precisely because its servers are allowed to forget. It's not a flaw that was tolerated; it's the trade that made the whole thing possible.
DO THE MATHS YOURSELF · WHAT "REMEMBERING EVERYONE" WOULD COST ONE SERVER
Say remembering one visitor's conversation costs a modest 2 KB of server memory. Drag the visitors up and watch the bill — versus the stateless server, which spends the same 0 KB at every scale.
RIGHT NOW
REMEMBERS EVERYONE
SERVER SPENDS — ALWAYS
visitors × 2 KB each = 2 MB of pure bookkeeping — manageable… for now. Keep dragging.
The "coupon" trick comes in two main flavours you'll hear about long before you build one: cookies — small labelled notes the server asks your browser to keep and automatically attach to every future request to that site — and tokens — signed passes the browser presents to prove who it is. In Unit 4, when you build your own server, you'll implement this yourself and statelessness will go from trivia to a design constraint you personally wrestle with.
Bonus vocabulary: engineers literally call these mechanisms "state management" — managing the memory HTTP refuses to carry.
Idea three
One page load, five steps — every single time.
You now know the language (HTTP) and its strange memory (none). Let's slow down one page load — the thing that takes under a second — into the five steps it always contains. This ladder is worth memorising: every debugging session for the rest of your career is about finding which rung broke.
Type an address, click a link, tap an app icon — every load starts with the client being told to fetch something. (Class 1's iron rule, still holding: the client always starts.)
Phrased in the standard format from today's Idea One, addressed to the server that holds the site, carried across the internet's roads from Class 1.
The web-server software looks in its folders for the requested file. Found it? Great. Not there? You get the web's most famous apology — 404 Not Found — which is simply this step failing, reported honestly.
A status ("200 OK" — the success code you'll come to love) plus a copy of the file. The original never leaves the server's disk.
It reads the HTML in the copy and paints actual text, images, and buttons. Rendering is the browser's whole talent — and from next class onwards, you'll be writing the very HTML it reads.
Under one second, five steps, two machines, one protocol. Web development is the craft of controlling what happens at both ends of this ladder.
Idea four
"Web server": the term with two honest meanings.
You've been hearing "server" since Class 1. Time to sharpen it, because the industry uses the word in two ways — and your exam paper asks about one of them, twice.
A physical computer — usually a slab in a rack in a data centre — that stays on 24/7 and is connected to the internet so it can be reached at any hour. No screen, no keyboard; just power, network, and disks full of files. When someone says "the server is in Mumbai," they mean this.
A program running on that computer whose entire job is: listen for HTTP requests, find the requested file, send back the response. Steps 3 and 4 of the ladder, performed millions of times a day without boredom. When an exam asks "what is a web server," this is the star of the answer.
Class 1 called websites "shops" on the internet's roads. Refine it: the building is the hardware — it exists, it has an address, it holds the stock. But a building sells nothing. The shopkeeper — hearing "one samosa," fetching it from the shelf, handing it over — is the web-server software. Same counter, two meanings, and the second one does all the work. From now on in this course, "web server" means the shopkeeper unless we say otherwise.
Q. What is a web server? [2M] / Define web server and give examples. [3M]
Ans. — definition first, then name names, then deeper than the marks ↓
A web server is software (running on an internet-connected computer) that listens for HTTP requests from clients and responds by locating and sending back the requested resources — HTML pages, images and other files.✓ 1
The term can also refer to the physical machine on which this software runs — say both in the exam; the nuance is a free half-mark.✓ ½
Examples: Apache HTTP Server — the long-standing open-source workhorse; Nginx — handles huge traffic efficiently.✓ 1
Microsoft IIS — for Windows systems; Node.js with Express — the one we will build with in Unit 4.✓ ½
Beyond the marks — the double meaning that trips students. “Server” names a role, not a shape — the same laptop you own could run Apache tonight and be a web server; a million-rupee rack machine running nothing is just metal. Software earns the title, hardware merely hosts it — which is why point 2's half-mark exists at all.✚ depth
definition + software/hardware nuance + 2–3 named examples = full marks ✓
Meet the four shopkeepers you just named.
The exam wants their names; a developer should know their faces. Ten minutes of reading, zero of it needed for today's build — but the next time an article mentions Nginx, you won't scroll past it blankly.
This course teaches the MERN stack — MongoDB, Express, React, Node. Notice what's missing: none of the classic standalone servers. That's deliberate. In the MERN world, your server is a program you wrote in JavaScript; Express handles the HTTP plumbing while you decide what each request gets back. One language from the browser to the server — that's the stack's whole sales pitch, and by Unit 4 you'll be living it.
Idea five
Everything you need to start building. It's two things.
Students routinely assume web development begins behind a wall of installations, licences, and powerful laptops. Here is the honest, complete list of what building web pages requires — and the reassuring list of what it doesn't.
Chrome, which you toured last class. It's both the audience for your work and — via the developer tools behind F12 — your inspection instrument. The renderer of step 5 of the ladder, sitting on your desktop, free.
HTML files are plain text — you could write them in Notepad. A code editor simply makes the writing humane: it colours your code so mistakes stand out, completes tags as you type, and manages whole project folders. Ours is VS Code — free, made by Microsoft, and the most widely used editor in the industry today.
HTML is not compiled, not executed as a program, and not fussy about hardware — the browser just reads it, like a very fast, very literal reader. The lab machines run everything in this course comfortably, and so will almost any personal laptop from the last decade.
A browser and an editor. The entry fee to the entire profession is two free downloads.
Install guide 1 of 2 · Do this along with the page
Install VS Code — carefully, together, once.
What: Visual Studio Code ("VS Code"), your code editor for all 48 classes and all 12 labs. Why now: your first HTML file is twenty minutes away and it deserves a proper home. Time: about five minutes on lab Wi-Fi. Follow the numbered dots — every click that matters has one.
This is a drawn illustration of the real page, matched to its current layout — colours simplified, positions faithful. The real site may shuffle its wording; the big download button is always front and centre.
Into the address bar — pointer ① — not into a search engine. Searching "vs code download" surfaces look-alike sites that bundle junk. Going straight to the address is a professional habit worth starting today: you know where the shop is; don't ask a stranger for directions.
The site detects your operating system and offers the right build (Windows in the lab). The file is roughly 90–100 MB; it lands in your Downloads folder.
Double-click VSCodeUserSetup-…exe in Downloads. Accept the licence agreement, then keep clicking Next — the defaults are right for us, with one screen worth a pause, shown below.
It's ticked by default — just don't untick it. This one checkbox lets other tools find VS Code later in the course, and its absence is a classic source of mysterious errors weeks from now. Tick, Install, wait for the green bar, Finish.
The same page gives you a .zip. Open it, then drag the Visual Studio Code app into your Applications folder — that drag is the installation. Launch it from Applications like any other app.
One more ritual while we're here: a home for your practice files.
Every file you create in this course will live in one tidy place — not scattered across the desktop like everyone's first semester of code. Sixty seconds, once, and "where did I save that?" never happens to you.
Press Win+D — every window minimises instantly. (Same keys bring them back.)
The menu below appears; the path to follow is highlighted. A folder called "New folder" appears with its name ready to be typed over.
All lowercase, one hyphen, no spaces — then press Enter. The naming rules below aren't fussiness; they're the first professional convention of this course.
Because folder names become parts of web addresses. A space in a name turns into the ugly %20 in a URL — you've seen it in broken links. And most web servers run on Linux, where capital letters matter: Menu.html and menu.html are two different files — a site that works on your Windows laptop can 404 the moment it's uploaded. All-lowercase-with-hyphens sidesteps both traps forever. Every professional repo you'll ever open is named this way.
Install guide 2 of 2 · Two minutes
One extension: Live Server.
Extensions are add-ons that teach VS Code new tricks. Live Server adds the best one for beginners: it shows your page in the browser and auto-reloads it every time you save — no manual reload, ever. And quietly, it is exactly what its name says: a tiny real web server, running on your machine, doing steps 3 and 4 of today's ladder for an audience of one. From next class, today's theory literally runs on your laptop.
Drawn illustration of the Extensions view, faithful to where things sit in the real editor. The publisher name matters: pick the one by Ritwick Dey — it's the overwhelmingly popular original.
Click the icon of four squares (one drifting away) in the left rail, or press Ctrl+Shift+X. The rail is VS Code's main corridor; this door leads to its add-on shop.
Type it in the search box at the top of the panel. Several similarly named results appear; the one you want says Ritwick Dey underneath.
A few seconds of spinner, then the button flips to a gear icon. Done — no restart needed.
When Live Server runs, your address bar will read something like 127.0.0.1:5500. That first number is the internet's strangest address: it always means "this very machine" — the loopback address, where your computer talks to itself. The :5500 is a port: one numbered door on that machine, out of 65,535 available. Your browser (client) will knock on door 5500 of your own laptop, and Live Server (server) will answer from inside the same laptop. The full client–server ladder, five centimetres of travel.
The moment
Your first HTML file. Six lines.
Tools installed, folder waiting. Now the promise gets kept. Open VS Code, and let's write the smallest complete web page that exists — then read every line of it like it matters, because it does.
<!DOCTYPE html>as line 1 — the declaration, always first, always exactly this.- An
<html>pair wrapping everything, a<body>pair wrapping the visible part. - One heading:
<h1>Hello, Web!</h1>— that exact text, opened and closed. - Saved as
hello.htmlinside your desktopfswd-practicefolder.
<!DOCTYPE html><html><body> <h1>Hello, Web!</h1></body></html>Hello, Web!
fswd-practice/ — the desktop folder you just madehello.html — lowercase, and the .html ending is the whole pointNotice the pattern already: tags come in pairs — an opener like <body> and a closer like </body> with a slash — and pairs sit inside other pairs, never overlapping. That single idea, meaning marked out by nested pairs, is the entire grammar of HTML. Next class we give it a proper name and a proper skeleton.
Sharp catch: you opened this page and no server was involved. The address bar proves it — it says file:///, not https://. Your browser read the file straight off your own disk: steps 1 and 5 of the ladder with the middle three skipped, because the file was already here. That's fine for a first hello — but it's also why your page is invisible to every other device on Earth. Making the middle steps happen — a server, an address, anyone able to visit — is exactly where this course is headed.
Your turn
Make the page yours: one missing line.
Below is your hello.html grown by one line — except the new line is blank. Fill it so the page shows, under the big greeting, a smaller line with exactly this text: K Student · Roll No 160123733001 — type it character-for-character so your render matches the answer sheet's browser preview exactly (swap in your own name and roll number only after it matches). You haven't been taught the tag you need — that's deliberate. You know <h1> is "heading, level one"… so take one guess at what a slightly-less-important heading might be called. Type your line into the real file in VS Code, save, and re-open it in Chrome.
- Fill line 5 only — every other line stays exactly as it is.
- The new line's text, character for character:
K Student · Roll No 160123733001. - It must render smaller than the h1 — pick the tag by its meaning (a slightly-less-important heading), not by styling.
- Open your tag and close it — same name, one slash, like line 4 does.
<!DOCTYPE html><html><body> <h1>Hello, Web!</h1> <- your line goes here: the text “K Student · Roll No 160123733001”, as a smaller heading</body></html>SAMPLE OUTPUT — YOUR FINISHED FILE MUST RENDER EXACTLY THIS
Hello, Web!
K Student · Roll No 160123733001
Hint 1: If level-one importance is h1, the naming scheme for level-two importance is not a wild guess away. Headings go down to level six.
Hint 2: Whatever tag you open, close — same name, one slash, like the h1 on line 4 does. If your page shows raw angle brackets as text, look at your closing tag first.
Answer sheet
The line, revealed.
Try your guess in the real file first — a wrong guess that renders teaches more than a right answer that's read.
<!DOCTYPE html><html><body> <h1>Hello, Web!</h1> <h2>K Student · Roll No 160123733001</h2></body></html>Hello, Web!
K Student · Roll No 160123733001
- Did you write a matching pair — <h2> opened and </h2> closed? If you forgot the slash, everything after your line probably went huge — congratulations, you've just experienced the dangling-tag bug, and you're now vaccinated against it.
- Is your line inside the body pair? A line placed after </body> may still display today, but it's outside the visible part by the rules — browsers just forgive it. Precision now saves debugging later.
- Did the h2 come out smaller than the h1 — without you specifying any size? Sit with that: you declared meaning ("second-level heading") and the browser chose the look. That inversion — meaning first, appearance follows — is the deepest habit in this entire course, and you just used it correctly on your first day of writing code.
Why the file must end in .html
The most common Class-2 casualty, in every batch: a perfectly written page that opens as plain text or refuses to open at all. The culprit is almost always the file's ending. Three files that look similar — and behave nothing alike:
The .html ending tells Windows and the browser: "this is a web page — render it." Tags become headings. This is yours.
Saved from Notepad, which quietly appends .txt — and Windows hides known endings, so it still displays as "hello.html". The browser shows your tags as raw text. Maddening, unless you know the trick below.
A Word file is not plain text — it's a compressed bundle of formatting data. Browsers can't render it as a page at all. Word is for essays; VS Code is for code. Never the twain.
Open File Explorer, open the View menu, tick File name extensions. Windows stops hiding endings forever, and "hello.html" that's secretly "hello.html.txt" is exposed on sight. Do this once on your laptop after class; it's permanent, and it converts the most confusing beginner bug into a thing you spot across the room. (VS Code users mostly never hit this trap — one more quiet reason we installed a real editor today.)
The ending doesn't transform the contents — hello.html and hello.txt can contain byte-for-byte identical text. The extension is a label that tells software how to treat the file. Rename a .html to .txt and back: nothing inside changes, only the treatment. That's also why renaming a .docx to .html can't make Word output into a web page — the label changed, the contents didn't keep the promise.
Closing the hour
What you can now do — that you couldn't an hour ago.
fswd-practice/hello.html — six lines that grew to seven, written by you, rendered by your browser. Keep it; you'll be oddly fond of it by Unit 5. Next class the real project begins — our campus food-court app, Poshtik Campus, gets its first folder and its first page, served by that "Go Live" button you installed today.
GIT? Not yet — and that's correct. fswd-practice\ is scratch paper: it will never be a git repository, today or any day. Git enters your life in Lab 1, watching one folder only — poshtik-campus\, the real project. Sandbox files get made, broken and thrown away freely; that freedom is the whole point of having a sandbox.
Before next class — three 15-minute pieces of homework:
Visit five sites you use daily and check the address bar of each: padlock or no padlock, https or http? Find even one plain-http site if you can — they're nearly extinct, and now you know exactly what went extinct and why.
In your hello.html, delete the slash in </h1>, save, reload. Watch what the page does. Put the slash back, fix the world. Breaking code deliberately, in a file that can't hurt anything, is how fear of breaking code fades away.
Go to any real site and edit its address to a page that can't exist — vce.ac.in/samosa, say. Read the 404 page you get and narrate the ladder: which step just failed, and which machine told you so?
Yesterday you learned who talks. Today you learned how — and wrote your first words in the conversation.
Two sentences: (1) What does it mean that HTTP is stateless? (2) When you opened hello.html in Chrome today, why was no web server needed — and what in the address bar proves it?