Orientation and Web Foundations
Establish how the web works, core protocols, and the tools and habits for succeeding in this course.
Content
HTTP and HTTPS basics
Versions:
Watch & Learn
AI-discovered learning video
HTTP and HTTPS Basics — How the Web Actually Talks (Without the Mystical Fog)
"This is the moment where the concept finally clicks." — probably you, after reading this.
You're already familiar with the client-server model and web architecture fundamentals from earlier in the course. Great — we'll treat that like the stage set and skip the opening monologue. Now the actors walk on: HTTP and HTTPS. These are the actual lines they speak.
What are HTTP and HTTPS in one dramatic sentence?
- HTTP (HyperText Transfer Protocol): the plain-language protocol browsers and servers use to exchange requests and responses — like a waiter taking your order and bringing back your meal.
- HTTPS: HTTP inside a locked, tamper-evident, notarized envelope — encrypted with TLS so eavesdroppers can't read or swap your order.
Both fit inside the client-server play you learned about: the browser (client) makes an HTTP request to a server (addressed by the URL + port), receives an HTTP response, and renders it.
The anatomy of an HTTP exchange (raw view)
Imagine peeking at the network. A simple GET looks like this:
GET /index.html HTTP/1.1
Host: example.com
User-Agent: curl/8.0
Accept: */*
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1256
<html>...</html>
Key parts
- Request line: method + path + version (e.g.,
GET / HTTP/1.1). - Headers: metadata (Host, User-Agent, Accept, Cookie, etc.).
- Empty line: separates headers from body.
- Body: optional payload (HTML, JSON, files).
Useful curl example to see this in real life:
curl -v https://example.com/
The -v prints request and response headers so you can inspect the conversation.
Common HTTP methods (not exhaustive, but the ones you'll meet constantly)
- GET — fetch a resource (idempotent; shouldn’t change server state).
- POST — submit data (create/update actions; not idempotent).
- PUT — replace a resource.
- DELETE — remove a resource.
- HEAD — like GET but only headers (no body).
Why care? Methods signal intent. Web servers and RESTful APIs depend on them.
Status codes — the server's mood ring
- 1xx: informational
- 2xx: success (200 OK, 201 Created)
- 3xx: redirects (301 permanent, 302 temporary)
- 4xx: client error (400 Bad Request, 401 Unauthorized, 404 Not Found)
- 5xx: server error (500 Internal Server Error)
A 404 isn't tragic — it's just the server telling your browser "we looked but couldn't find that file."
Headers: tiny notes with huge power
Headers control caching, content negotiation, cookies, CORS, and security policies. Examples you’ll see often:
Content-Type: what the body is (e.g.,text/html,application/json).Set-Cookie: server tells browser to store a cookie.Cache-Control: caching rules.Authorization: bearer tokens, Basic auth, etc.Host: which website (important for virtual hosting).
Pro tip: browser DevTools Network tab is your best friend for inspecting headers.
HTTP is stateless — what that really means
Each request is independent. The server doesn’t remember you between requests unless you give it a mechanism (cookies, tokens, server-side sessions). Think of statelessness as a policy of zero memory: every message must carry what’s needed.
Why HTTPS matters (spoiler: everything)
HTTP is readable by anyone who can intercept the packets (Wi-Fi snoopers, malicious routers, ISP, your neighbor with way too much interest in your browsing). HTTPS protects you in three ways:
- Confidentiality — encryption hides the content.
- Integrity — tamper detection prevents on-the-fly modification.
- Authentication — certificates prove the server is who it claims to be.
Imagine sending a postcard (HTTP). Anyone along the post route can read and change it. HTTPS is a sealed, signed envelope — the mail carrier can't open it without it being obvious.
TLS handshake (very short, hand-wavy, but useful)
- Client Hello: browser says "Hi, I want to talk securely. Here are the ciphers I support."
- Server Hello: server picks a cipher and sends its certificate (contains its public key and identity).
- Client verifies certificate (chain to trusted CA). If OK, client generates a symmetric key, encrypts it with the server's public key, and sends it.
- Both sides now share the symmetric key for fast encryption.
- Secure session established; proceed to HTTP over TLS (HTTPS).
Notes:
- Modern TLS uses ephemeral keys (Perfect Forward Secrecy) so past sessions can't be decrypted if keys are leaked later.
- Certificate Authorities (CAs) are the notaries that you trust to validate identities. Let's Encrypt automated this for the masses.
Ports, URLs, and browser behaviors
http://defaults to port 80https://defaults to port 443
Browsers will often redirect http:// to https:// if the site supports HSTS (HTTP Strict Transport Security). Mixed content (HTTPS page loading HTTP resource) is blocked or warned because it’s a weak link.
Quick checklist for a secure, modern site
- Serve pages over HTTPS only (redirect HTTP to HTTPS).
- Obtain certificates from a trusted CA (Let’s Encrypt is free and automated).
- Use HSTS to force browsers to use HTTPS.
- Set secure headers:
Content-Security-Policy,X-Frame-Options,Strict-Transport-Security. - Avoid mixed content; use relative or HTTPS URLs for assets.
When to care in CS50 Web Programming
- When you build routes and APIs: choose methods & status codes appropriately.
- When you handle authentication: always use HTTPS to protect credentials and tokens.
- When you debug: read headers and raw requests in DevTools or via curl.
This builds directly on the client-server model and the architectural pieces you already studied — now you're watching their actual conversation and learning how to secure it.
Key takeaways
- HTTP is the protocol for requests/responses; HTTPS is HTTP guarded by TLS.
- Inspect requests with curl or browser DevTools to learn how headers and bodies interact.
- HTTPS provides confidentiality, integrity, and authentication — don't skimp on it.
Final memorable line: Think of HTTP as talking in a crowded room and HTTPS as whispering in a vault with a signed receipt. Same words, wildly different privacy.
Further practice exercises (quick)
- Use
curl -v http://example.com/andcurl -v https://example.com/. Compare headers and observe the TLS handshake for HTTPS. - Open DevTools → Network → reload a page. Inspect a request’s headers, response, and timing.
- Try to load an
http://resource from anhttps://page and observe mixed-content behavior.
Happy sleuthing. You've moved from knowing the stage to understanding the script—next up: how to change the plot (sessions, cookies, authentication).
Comments (0)
Please sign in to leave a comment.
No comments yet. Be the first to comment!