DEV Community

Yukti Sahu
Yukti Sahu

Posted on

🔥 Understanding HTTP Deeply — The Backbone of the Web (For Backend Learners)

#development #networking #security #web3

You tryna be a backend dev but HTTP is still a mystery? That’s not very slay of you
o

When you step into backend development, you quickly realize that knowing HTTP is not optional. It's the foundation of how clients and servers talk, how browsers fetch your apps, how APIs work, how authentication happens — everything.

This article explains HTTP in a simple but deeply technical way, covering:

  • Statelessness
  • Client–Server Model
  • Evolution of HTTP (HTTP/0.9 → HTTP/3)
  • Headers and Their Types
  • Idempotency
  • Methods and Use Cases
  • CORS & OPTIONS
  • Status Codes
  • SSL/TLS & HTTPS
  • Real examples

Let’s begin. 🚀

1. HTTP is Stateless — What Does That Actually Mean?

Stateless means:

  • The server does not remember anything about previous requests.
  • Every request is independent.

If a client sends 5 requests, the server treats each one as a fresh request with no memory of previous interactions.

Why is HTTP stateless?

  • Server doesn’t store user info → architecture becomes simple.
  • Scaling becomes easier → any server can handle the next request.
  • If one server crashes, user is not affected (because the client re-sends credentials).

If HTTP is stateless, how do websites keep you logged in?

Developers implement state management using techniques such as:

  • Cookies
  • Sessions
  • JWT tokens
  • OAuth
  • localStorage (client-side)

Each request carries user identity again and again.

Example request (showing stateless nature) 

GET /profile HTTP/1.1
Host: example.com
Authorization: Bearer <token>
Cookie: session_id=abc123
Enter fullscreen mode Exit fullscreen mode

Every request must re-send credentials because the server doesn't remember previous requests.

2. The Client–Server Model

HTTP follows the Client–Server architecture.

Client

Anything that sends a request:

  • Browser
  • Mobile app
  • React/Next.js frontend
  • Postman/cURL

Server

Hosts:

  • APIs
  • Database access logic
  • Files & resources
  • Authentication

Basic flow

Client → sends Request → HTTP → Server

Server → sends Response → HTTP → Client

Medium of communication → TCP.

HTTP runs on top of TCP (Transmission Control Protocol). TCP ensures:

  • Reliable message delivery
  • No data loss
  • Ordered packets

3. Evolution of HTTP (Important for interviews)

  • HTTP/0.9 (1991)

    • Only GET, no headers, response was plain text.

  • HTTP/1.0 (1996)

    • Headers introduced. Each request opens + closes connection → slower.

  • HTTP/1.1 (1999)

    • Persistent connections, chunked responses, caching headers.
    • Default for many years and still widely used.

  • HTTP/2 (2015)

    • Binary protocol, multiplexing (many requests in one connection), HPACK header compression → faster.

  • HTTP/3 (2022)

    • Based on QUIC (UDP). Zero head-of-line blocking, faster on unstable networks.

4. Understanding HTTP Headers

Headers = metadata sent with requests and responses. They tell the server:

  • Who is requesting?
  • What format is expected?
  • What content is being sent?
  • What authentication is used?

Categories of headers

1) Request headers

Tell the server about the client.

Examples:

User-Agent: Mozilla/5.0
Authorization: Bearer <token>
Cookie: session_id=abc123
Accept: application/json
Enter fullscreen mode Exit fullscreen mode

2) General headers

Used in both request and response:

  • Cache-Control: no-cache
  • Connection: keep-alive
  • Date: Tue, 15 Nov 2025

3) Representation headers

Tell about the actual payload/data:

  • Content-Type: application/json
  • Content-Length: 532
  • Content-Encoding: gzip
  • ETag: "9b1f..."

4) Security headers

Used to harden web apps:

  • Strict-Transport-Security: max-age=31536000; includeSubDomains
  • Content-Security-Policy: default-src 'self'
  • X-Frame-Options: DENY
  • X-Content-Type-Options: nosniff
  • Set-Cookie: session_id=abc123; HttpOnly; Secure

Why is HTTP extensible?

You can add custom headers without changing the protocol. Examples:

  • X-Client-Region: India
  • X-App-Version: 3.1.0

These are useful for telemetry, experimentation, versioning or additional security metadata.

Headers are like remote controls for servers. Examples:

  • Client -> “Send JSON only.”

    • Accept: application/json

  • Client -> “Store this only for 1 hour.”

    • Cache-Control: max-age=3600

  • Client -> “Send compressed data.”

    • Accept-Encoding: gzip

5. HTTP Methods & Their Intent

Method Use case
GET read data
POST create data
PUT update (replace)
PATCH update (partial)
DELETE remove resource
OPTIONS discover server capabilities (CORS)

6. Idempotent vs Non-Idempotent

Idempotent (same result even if request is repeated):

  • GET
  • PUT
  • DELETE

Non-idempotent:

  • POST

Example:

POST /order — if you send the same request twice -> two orders are created.

7. OPTIONS and CORS

Browsers enforce CORS for cross-origin security.

Two types of requests:

1) Simple request

  • No preflight. Usually GET/POST with safe headers.

2) Preflighted request

  • Browser first sends an OPTIONS preflight to check permissions.

Example preflight request:

OPTIONS /api/data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Enter fullscreen mode Exit fullscreen mode

Server replies with allowed origins & methods:

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: POST
Enter fullscreen mode Exit fullscreen mode

After a successful preflight, the browser sends the actual request.

8. HTTP Response Status Codes

  • 200–299 → Success

    • 200 OK
    • 201 Created
    • 204 No Content

  • 300–399 → Redirection

    • 301 Moved Permanently
    • 302 Found

  • 400–499 → Client errors

    • 400 Bad Request
    • 401 Unauthorized
    • 403 Forbidden
    • 404 Not Found
    • 429 Too Many Requests

  • 500–599 → Server errors

    • 500 Internal Server Error
    • 503 Service Unavailable

Example response 

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "message": "User fetched successfully"
}
Enter fullscreen mode Exit fullscreen mode

9. SSL, TLS & HTTPS (expanded)

HTTP by itself is not secure — data travels in plain text. SSL/TLS provide confidentiality, integrity, and authentication for HTTP, resulting in HTTPS (HTTP over TLS).

A brief history

  • SSL: the original Secure Sockets Layer (SSL 2.0/3.0) is now deprecated because of several design flaws and vulnerabilities.
  • TLS: Transport Layer Security replaced SSL. Major TLS versions: TLS 1.0 / 1.1 (deprecated), TLS 1.2 (widely used), and TLS 1.3 (recommended).

What TLS provides (concise)

  • Confidentiality — encrypts the payload so eavesdroppers can't read it.
  • Integrity — ensures data isn't tampered with in transit (via MACs or AEAD).
  • Authentication — ensures the client is talking to the genuine server via certificates.

TLS handshake — a deeper look

The handshake establishes cryptographic parameters and shared keys. High-level steps (TLS 1.2 style, then notes for TLS 1.3):

  1. ClientHello: the client sends supported protocol versions, cipher suites (e.g., ECDHE + AES-GCM), supported extensions (SNI, ALPN), and a random value.
  2. ServerHello: the server picks a protocol version and cipher suite and sends its certificate chain (leaf certificate + intermediate CA certs) and its ServerHello random.
  3. Certificate verification: the client validates the server certificate chain up to a trusted root, checks validity dates, host name (or SAN), and revocation status (CRL/OCSP).
  4. Key exchange: depending on the cipher suite, the client and server perform an asymmetric key exchange (ECDHE is common) to derive a shared secret. ECDHE provides forward secrecy; RSA key-exchange (deprecated for forward secrecy) is no longer recommended.
  5. Finished messages: both sides derive symmetric keys (for the record layer) and exchange Finished messages to validate the handshake integrity.

Notes:

  • In TLS 1.3 the handshake is streamlined: the number of round-trips is reduced, RSA key-exchange is removed, and forward-secret key exchange (ECDHE) is always used. TLS 1.3 also mandates modern AEAD ciphers (like AES-GCM or ChaCha20-Poly1305).
  • TLS supports session resumption (session IDs or session tickets) and in TLS 1.3 0‑RTT for some scenarios (with replay risks to consider).

Certificate basics

  • Certificates are signed by Certificate Authorities (CAs). A certificate contains the server's public key, the domain name(s) (CN / SAN), and validity dates.
  • The client verifies the signature chain up to a trusted root CA present in its trust store.
  • Let's Encrypt is a widely used free CA with automation for issuance and renewal.
  • Self-signed certificates work for local development but are not trusted by browsers.

Common cryptographic elements

  • Public-key algorithms: RSA (older), ECDSA (preferred for smaller key sizes and performance).
  • Key-exchange: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for forward secrecy.
  • Symmetric ciphers / AEAD: AES-GCM, AES-CCM, ChaCha20-Poly1305.
  • Hashes / HKDF: used in key derivation.

Practical deployment tips for backend developers

  • Prefer TLS 1.3 where possible; otherwise, require at least TLS 1.2.
  • Disable TLS 1.0 and 1.1 and avoid older cipher suites (RC4, DES, 3DES, MD5-based MACs, non-AEAD modes).
  • Prefer ECDHE key exchange for forward secrecy.
  • Use HSTS (Strict-Transport-Security header) to force browsers to use HTTPS.
  • Redirect all HTTP traffic to HTTPS (301 redirect), and set Secure and HttpOnly flags on cookies.
  • Automate certificate issuance & renewal (Let's Encrypt + ACME clients like certbot) and monitor expiry.
  • Enable OCSP stapling to improve revocation checking performance.
  • Test your configuration with tools like SSL Labs (Qualys) and Mozilla Observatory.

TLS-specific server headers & features to consider

  • Strict-Transport-Security: enforces HTTPS (example: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload).
  • OCSP Stapling: avoid clients having to fetch OCSP from CA networks.
  • ALPN (Application-Layer Protocol Negotiation): enables HTTP/2 or HTTP/3 negotiation during the TLS handshake.

Security features and advanced topics

  • Forward Secrecy: ensures that even if a server's long-term key is compromised later, past sessions remain confidential (use ECDHE).
  • Certificate Pinning: binds a service to a specific certificate/public key (use with caution — difficult to rotate).
  • Mutual TLS (mTLS): both client and server present certificates; useful for service-to-service authentication.
  • TLS 1.3 improvements: fewer round trips, mandatory forward secrecy, removal of insecure primitives, improved performance on lossy networks.

Quick checklist for a secure HTTPS deployment

  1. Use TLS 1.3 (or TLS 1.2 minimum).
  2. Prefer ECDHE + AEAD ciphers (AES-GCM, ChaCha20-Poly1305).
  3. Enable HSTS and set Secure, HttpOnly on cookies.
  4. Automate cert issuance & renewal; monitor expiry.
  5. Test with SSL Labs and fix warnings (protocols, key sizes, chain issues).

10. Code Examples

Fetch API (frontend) 

fetch("https://api.example.com/user", {
  method: "GET",
  headers: {
    "Authorization": "Bearer token123",
    "Accept": "application/json"
  }
})
.then(res => res.json())
.then(data => console.log(data));
Enter fullscreen mode Exit fullscreen mode

Node.js (Express) example 

app.post("/login", (req, res) => {
  const { email, password } = req.body;

  if (!email || !password) {
    return res.status(400).json({ error: "Missing fields" });
  }

  return res.status(200).json({ token: "jwt-token-here" });
});
Enter fullscreen mode Exit fullscreen mode

Final thoughts

HTTP may seem simple, but it's one of the most powerful and important protocols in computer science and backend development.

Once you understand:

  • statelessness
  • headers
  • authentication
  • CORS
  • TLS
  • the protocol's evolution

—you can design scalable, secure, modern backend systems.

Top comments (0)