Understand HTTP and Web Jargon's
Decode HTTP and Web Jargon with Real-Life Analogy
Table of contents
- What is HTTP ?
- How Does HTTP Work ?
- HTTP Components
- What is a Stateless Protocol ?
- Challenge of Stateless Protocols
- What is a Session, Cookies and Tokens ?
- HTTP Headers
- Types of HTTP Requests and Responses
- What is HTTP/2 ?
- Web Jargon’s
- How HTTPS (HTTP/2) Works :- Browser-Server Communication Explained
- Thank you for reading this far.😊
What is HTTP ?
Before we get started with HTTP, let us imagine: You wish to purchase some candy from a store as a consumer. The steps involved are as follows:
When you enter the store as a consumer, you inform the owner of your needs.
The store owner will hear you and see if your requested candies are in stock.
The store owner will bag the candy and offer it to you if they have any.
You accept the candy and savour it..
Now to summarize the above scenario in the context of HTTP :-
An HTTP request is when you (the browser) ask for candy.
The store owner (the server that provides what you requested) checks and provides candy (HTTP Response).
The shop and the customer communicate via HTTP.
Now get into the technical meaning of HTTP :-
A set of guidelines known as HTTP (HyperText Transfer Protocol) facilitates computer-to-computer communication via the Internet. It functions similarly to the language people use to request and exchange data, including files, videos, photos and web pages.
How Does HTTP Work ?
Consider HTTP to be a dialogue:
The web browser is You (the individual or customer inquiring): A REQUEST is sent to a website server by your browser (such as Chrome or another browser) asking for information. For instance: "Hey, may i view www.example.com homepage?"
The person answering is the server who works as a shopkeeper: After receiving and processing your request, the website's server returns a RESPONSE. For instance: "Sure! This is the webpage you requested”.
You see the outcome after receiving the response: The webpage you requested is displayed by your browser, which also makes it appear user-friendly and appealing.
HTTP Components
Request :- Your browser sends a message to the server requesting the page when you click on a link or put in a website address (such as www.google.com). Saying "Can I have this information, please?" is analogous to that.
Response :- The data (such as text, photos or videos) is returned by the server in response to your request. Saying "Here's what you asked for!".
Stateless Protocol (we will go deep into this topic in the next section) :- HTTP is unable to "remember" your previous actions. Every request is separate. It is similar to entering a store, making a purchase and then walking out. The merchant is unaware that you were in his or her store earlier if you go back to buy the similar item.
What is a Stateless Protocol ?
Every contact between a client (such as your web browser) and a server (such as a website) in a stateless protocol is autonomous and unreliant on any prior exchanges or states (no memory of prior requests). The server has no records of your past activities or personal information. Stateless protocols function by making each interaction independent of previous visits.
Real-Life Example :- It is similar to entering a store, making a purchase and then walking out. The merchant is unaware that you were in his or her store earlier if you go back to buy the identical item.
How HTTP is Stateless
When a website is opened, your browser requests a webpage from the server using HTTP. In response, the server forwards the document to your browser and then ignores the exchange. The server has no idea who you are and what you previously looked at or whether you have visited the location before. Every request and answer is separate.
Why is HTTP Stateless ?
Simplicity: Handling each request without having to keep track of its past status makes things easier.
Scalability: Since the server does not have to remember each user's information, it can accommodate more users.
Flexibility: There is no need to "connect the dots" between requests because each one is handled independently.
Challenge of Stateless Protocols
Certain features (such preserving your shopping cart or remaining signed into a website) are not available by default because the server does not remember you. Sessions or tokens are employed to solve this cookie problem. While sticking to the stateless principle, these tools assist the server in maintaining certain information as needed.
What is a Session, Cookies and Tokens ?
Session :-
A session can be thought of as a brief dialogue between a website and you (the client). It begins when you access a website and concludes when you log off. Consider it a kind of "notebook" that the server utilizes to record information about you while you are on the website such as:
Are you signed in?
What do you have in your cart?
Which page did you just visit?
Real-Life Example of a Session :-
Let us say you go to a pizza shop :-
As soon as you enter, you inform the employees what kind of pizza you want or prefer.
On an order slip ("session"), they record it.
While they make your pizza, they hold onto the slip.
They discard the slip once you take your pizza.
Cookies :-
In order to assist the server "remember" things between visits, your browser stores small notes called cookies.
For instance: Preserving a Preference
A cookie may be saved in your browser if you visit a pizza website and choose "Extra Cheese" as your preferred pizza.
The server automatically displays the extra cheese option the next time you come after reading the cookie.
The location of cookies' storage:
- Your device (your browser) stores cookies.
Purpose:
To keep in mind brief facts such as:
Login details.
Preferences (dark mode, language).
Analytics (the number of times you have been to a page).
Real-Life Example of Cookies :-
Situation: Recalling Your Preferences on an Online Store
You go to an online store (like Amazon) and choose Dark Mode as your theme of choice.
A cookie with the message "theme = dark mode" is saved by the website in your browser.
The cookie is returned to the server the next time you visit the website. After reading it, the website shows you the Dark Mode without your further request.
Important Points :-
Cookies store minor data, such as language, cart contents, and preferences.
Until you remove them or they expire, they remain in your browser.
Tokens :-
Tokens are like digital "keys" used to prove your identity, especially in secure systems.
How Tokens Work :-
The server verifies your identity by providing you with a token (unique combination of letters and numbers) when you log in.
Every time you make a request, such as opening a new page, you send this token which the server uses to confirm your identity.
The location of token storage:
- Tokens can be kept in the secure storage on your device or in your browser, just like cookies.
Purpose:
Since tokens are more secure than conventional techniques, they are frequently utilized in contemporary online apps (such as APIs).
They are extensively utilized in authorization protocols for services like Twitter, Facebook,and Google logins.
Real-Life Example of Tokens :-
Situation: Using Google to Log into an App
You click "Log in with Google" after launching an app like Spotify.
Google requests that you log in and use your username and password to confirm your identity.
After a successful login, Google creates a token (a unique key) and sends it back to Spotify. This token says: “This person is verified by Google.”
With the help of this token, Spotify allows you to access your account without requesting your password.
The app sends the token to the server each time you use Spotify to verify that you are logged in such as when you play a song or change your profile. (You must log in again to obtain a new token if the current one expires).
Feature | Session | Cookies | Tokens |
Stored Where ? | On the server. | On the client (browser). | On the client (browser or secure storage). |
Purpose | Tracks user activity while logged in. | Remembers small info (like preferences). | Authenticates and secures requests. |
Lifespan | Ends when you log out or after inactivity. | Can persist for days, months or years. | Usually short-lived but renewable. |
Security | Relatively secure (data stays on server). | Less secure (stored on the client device). | Highly secure (can be encrypted and signed). |
Example Use | Keeping you logged in while shopping online. | Remembering your favourite pizza topping | Logging in with Google on a third-party app. |
Example :- Using All Three Together
You log into a shopping website:
- A session is created on the server to track your activity.
The website remembers your preferences (like dark mode):
- A cookie is saved on your browser to store that info.
If you log in using a third-party service (like Google):
- A token is issued to securely prove your identity.
In Simple Words :-
Session :- The server’s way of keeping track of you while you’re using the website.
Cookie :- A tiny note saved in your browser to remember things for future visits.
Token :- A secure key that proves you are who you say you are often used in modern secure apps.
HTTP Headers
Header Name | Description | Example Value |
Host | Specifies the domain name of the server being requested. | example.com |
Content-Type | Describes the type of data being sent or received. | text/html |
Authorization | Used for secure access, like logging in. | token12345 |
Cookie | Sends cookies stored in the browser to the server. | session_id=abc123 |
Cache-Control | Tells the browser or server how to cache the response. | no-cache, max-age=3600 |
Accept | Specifies what type of response the browser expects. | text/html |
User-Agent | Provides information about the browser or device. | Chrome |
Why Are HTTP Headers Important ?
For the Client (Browser) :-
They help the browser tell the server exactly what it wants and how it can handle the response.For the Server :-
They allow the server to customize the response based on the client’s needs (i.e. sending mobile-friendly pages).
Real-Life Example of HTTP Headers
Let’s say you’re ordering pizza online :-
Request Headers (from you):
User-Agent :- Chrome on phone (Telling the pizza website you’re on a mobile browser).
Accept :- text/html (You want to see a webpage, not plain text or something else).
Response Headers (from the pizza website):
Content-Type :- text/html (The website says, “Here’s a webpage with your pizza menu”).
set-Cookie :- cart_id=12345 (The website saves a cookie so it remembers your order later).
HTTP headers are like instructions or notes that explain how to handle the request and response. They make communication between your browser and the server more efficient.
Types of HTTP Requests and Responses
1. HTTP Requests
When your browser or app wants something from a server (like a webpage), it sends an HTTP request. Think of it as asking a question or giving instructions to the server.
Common Types of HTTP Requests (Methods) :-
GET
Purpose :- Ask the server for information (like a webpage, image, or data).
Example :- You type google.com in your browser; your browser sends a GET request asking Google to show its homepage.
Real-Life Analogy :- Going to a library and saying, “Can I see this book?”
POST
Purpose :- Send data to the server (usually to create or submit something).
Example :- When you fill out a form online (like signing up for a website) and click "Submit," your browser sends a POST request with the form data.
Real-Life Analogy :- Sending a letter to the library saying, “Here’s my review of the book I borrowed.”
PUT
Purpose :- Update existing information on the server.
Example :- When you edit your profile on a website and save the changes, a PUT request is sent with your updated data.
Real-Life Analogy :- Telling the library, “Please update my phone number in your records.”
DELETE
Purpose :- Request to delete something from the server.
Example :- If you delete a post on social media, your browser sends a DELETE request to remove it.
Real-Life Analogy :- Asking the library to remove your name from the membership list.
PATCH
Purpose :- Partially update information on the server (just one piece, not the whole thing).
Example :- Changing only your email in your profile without touching the rest.
Real-Life Analogy :- Telling the library, “Change my street address but keep the city and state the same.”
OPTIONS
Purpose :- Ask the server what it can do or what methods it supports.
Example :- Before sending data, your browser might ask, “Hey server, can I use POST here?”
Real-Life Analogy :- Asking the librarian, “What kinds of books can I borrow?”
HEAD
Purpose :- Similar to GET but only asks for the headers, not the full content.
Example :- Your browser might check if a webpage exists without downloading it.
Real-Life Analogy :- Asking the library, “Do you have this book in stock?” but not actually reading it.
2. HTTP Responses
Once the server receives the request, it processes it and sends back a response :-
A Status Code :- Indicates whether the request was successful or not.
Headers :- Extra information about the response.
Body (optional) :- The actual content (like a webpage or error message).
Common Types of HTTP Responses (Status Codes) :-
(Here 1xx, 2xx, … means 100, 102, 200, 201, …)
1xx – Informational Responses
Meaning :- The server received your request and is still processing it.
Example :- "Hold on, I’m looking for the book!"
2xx – Success
Meaning :- The request was successful, and the server is sending the requested data.
Examples :-
200 OK :- Everything worked.
- Real-life analogy: “Here’s the book you asked for.”
201 Created :- Something was successfully created (like a new account).
- Real-life analogy: “We’ve added your review to our records.”
3xx – Redirection
Meaning :- The content you’re looking for is somewhere else.
Examples :-
301 Moved Permanently :- The book has been moved to another section permanently.
302 Found :- The book is temporarily in another section.
Real-Life Analogy: The librarian says, “The book is now on the 2nd floor.”
4xx – Client Errors
Meaning :- There’s something wrong with your request.
Examples :-
400 Bad Request :- The server didn’t understand your request.
- Real-life analogy: “Your note is unreadable.”
401 Unauthorized :- You need to log in to access the content.
- Real-life analogy: “You need a library card to borrow books.”
400 Not Found :- The server couldn’t find what you’re asking for.
- Real-life analogy: “The book you’re looking for doesn’t exist.”
5xx – Server Errors
Meaning :- Something went wrong on the server’s side.
Examples :-
501 Internal Server Error :- The server is broken or can’t process the request.
- Real-life analogy: “The librarian dropped the books and can’t find them.”
503 Service Unavailable :- The server is overloaded or under maintenance.
- Real-life analogy :- “The library is temporarily closed.”
Code Range | Category | Meaning | Examples |
1xx | Informational | Processing request | 100 Continue, 102 Processing |
2xx | Success | Request worked | 200 OK, 201 Created, 204 No Content |
3xx | Redirection | Resource moved | 301 Moved Permanently, 302 Found |
4xx | Client Errors | Something wrong on your side | 400 Bad Request, 404 Not Found, 403 Forbidden |
5xx | Server Errors | Something wrong on the server’s side | 500 Internal Server Error, 503 Service Unavailable |
Example of a Request-Response Cycle
Let’s say you visit a pizza delivery website :-
Request :- Your browser sends a GET request asking for the menu.
Response :- The server sends back a 200 Ok response with the menu.
Request :- You submit an order, which sends a POST request to the server with your pizza details.
Response :- The server sends back a 201 Created response saying, “Your order is confirmed.”
In Simple Words :-
HTTP Requests :- What your browser asks the server to do (i.e. GET = give me this webpage, POST = send this form data).
HTTP Responses :- What the server sends back (i.e. 200 = everything’s fine, 404 = can’t find what you’re looking for).
What is HTTP/2 ?
HTTP/2
HTTP/2 is an improved version of HTTP/1.1 (HTTP/1.1 is a specific version of the HTTP protocol) that makes websites load faster, more efficient and more secure. It keeps the same basic job as HTTP :- transferring data between your browser and a server. But it does this in a smarter way, solving many of HTTP/1.1 limitations.
Think of it as upgrading from an old single-lane road (HTTP/1.1) to a modern multi-lane highway (HTTP/2), allowing more cars (data) to travel faster and with fewer traffic jams.
Why Was HTTP/2 Needed?
HTTP/1.1 Was Slow :-
Each request (like loading an image or video) had to be processed one at a time, creating delays.
If you wanted a lot of things (like a webpage with many images), the browser had to make multiple connections which slowed things down.
Websites Became More Complex :-
- Modern websites have lots of images, videos and scripts which made the limitations of HTTP/1.1 more noticeable.
Key Features of HTTP/2
Multiplexing :-
In HTTP/1.1, each request (like an image, script, or video) needed its own connection which lead to bottlenecks ( bottlenecks means a narrow piece of path that causes traffic to slow down or stop).
HTTP/2 allows multiple requests and responses to travel at the same time on a single connection.
Real-Life Analogy :- Instead of waiting in line to buy items one at a time, now you can grab everything at once.
Header Compression :-
HTTP/1.1 sent repetitive data (headers) with every request which wasted bandwidth.
HTTP/2 compresses headers to reduce the amount of unnecessary data being sent.
Real-Life Analogy :- Instead of writing your name on every page of a form, you only write it once and reuse it.
Stream Prioritization :-
HTTP/2 lets browsers decide which parts of a webpage (like the text, images or videos) are most important and load them first.
Real-Life Analogy :- It’s like organizing your grocery bag so you grab the milk first, not the chips.
Single Connection :-
HTTP/2 uses only one connection between the browser and the server, even for large, complex websites.
This reduces the overhead and makes everything faster.
Real-Life Analogy :- Instead of making several trips to the grocery store, you load everything into one car and go once.
Server Push :-
The server can predict what you’ll need next and send it before you even ask.
Real-Life Analogy :- If you ask for a burger, the server also sends fries and a drink because it knows you’ll probably want them.
Benefits of HTTP/2
Faster Website Loading :- Multiplexing and header compression make webpages load much faster.
Better for Mobile Browsing :- Reduces delays and works better with slower mobile networks.
Saves Bandwidth :- Compressing headers and sending fewer connections means less data is used.
Improved Security :- HTTP/2 is often used with HTTPS (secure connections), making it safer.
Real-Life Example of HTTP/2
Let’s Compare HTTP/1.1 vs HTTP/2 When Loading a Webpage :-
HTTP/1.1 :-
The browser requests a webpage.
Then requests images one at a time.
Then requests styles and scripts, all one after the other.
This creates delays because requests are waiting in line.
HTTP/2 :-
The browser requests the webpage, and everything is downloaded at the same time.
The server sends text, images, scripts and videos in parallel with no waiting.
The webpage loads much faster.
NOTE :- HTTP/2 is Backward Compatible. If a server or browser doesn’t support HTTP/2, it will automatically switch to HTTP/1.1. This ensures everything works smoothly.
Feature | HTTP/1.1 | HTTP/2 |
Connections | One request per connection. | Multiple requests on a single connection. |
Speed | Slower due to delays. | Much faster due to multiplexing. |
Headers | Repeated with every request. | Compressed to save bandwidth. |
Server Push | Not available. | Predicts and sends what you need. |
Efficiency | Makes multiple connections for large data. | Uses one efficient connection. |
Web Jargon’s
User Agent (Browser) :-
What it is :- A software application like Chrome, Firefox or other browsers that allows you to browse the internet.
Why it matters :- The browser communicates with web servers to fetch and display web pages for you.
TCP (Transmission Control Protocol) :-
What it is :- A communication standard that allows computers to send data over a network reliably.
How it works :- It ensures the data (like a file or web page) is split into small packets, sent across the internet, and reassembled in the correct order on the receiving end.
FTP (File Transfer Protocol) :-
What it is :- A method to transfer files between computers over the internet.
Why it’s useful :- Helps upload or download files from a remote server (like transferring a website to a hosting server).
IP (Internet Protocol) :-
What it is :- A set of rules that govern how data is sent from one computer to another over the internet.
Why it’s important :- Every device on the internet has a unique IP address, which acts like a "home address" to identify where data should go.
URL (Uniform Resource Locator) :-
What it is :- The web address you type in your browser to visit a website (i.e. google.com).
Why it matters :- It tells the browser which website or specific resource (like a file or image) you want to access.
DNS (Domain Name System) :-
What it is :- A system that converts easy-to-remember domain names (like google.com) into IP addresses (like 192.168.1.1).
Why it’s needed :- Computers use IP addresses to communicate but humans find it easier to remember names instead of numbers.
Headers :-
What they are :- Additional information sent with a web request or response.
Example :- Headers can include details like the type of browser you’re using or whether you’re logged in.
Why it matters :- Helps the server and browser exchange information properly (i.e. telling the server what format to send data in).
Payload :-
What it is :- The actual data sent in a request or response (i.e. your email and password when logging into a website).
Why it’s important :- The payload carries the core information needed to process your request.
Cache :-
What it is :- A storage location where data is saved temporarily.
How it helps :- It saves copies of web pages, images, and other resources so they load faster the next time you visit the same site.
How HTTPS (HTTP/2) Works :- Browser-Server Communication Explained
1. Setup TCP Connection :-
- The browser (like Chrome or Firefox) connects to the server (where the website is hosted) using a communication protocol called TCP (Transmission Control Protocol). This is like setting up a phone call to ensure both sides can talk to each other.
2. Exchange TLS Certificates :-
- If the website uses HTTPS (a secure version of HTTP), the browser and server exchange something called a TLS (Transport Layer Security) certificate. This certificate ensures that the connection is secure, private and protected from hackers. Think of it as a digital handshake that establishes trust.
3. Send Request (Verb, URL, Data, etc.) :-
After the connection is secure, the browser sends a request to the server. This request includes:
Verb :- The type of action (like GET to fetch data, POST to send data, etc.).
URL :- The address of the webpage (like example.com/home).
Data :- Additional information the server might need (i.e. form inputs).
Headers :- Extra details (like your browser type or language preferences).
4. Get Response Back :-
The server processes the request and sends back a response to the browser. This response contains:
Status Code :- Indicates if the request was successful (i.e. 200 for success, 404 for not found).
Data:- The content of the webpage (like text, images, or files).
5. Close TCP Connection :-
- Once the browser receives the data, the connection is closed. This is because HTTP is stateless meaning it doesn’t keep the connection open after the interaction is complete.