HTTP & HTTPS

What is HTTP?

HTTP, the HyperText Transfer Protocol, is how clients and servers talk on the web. A client sends a request describing what it wants; a server sends a response describing what happened. Every page load, API call, image and font travels this way.

It is a simple, text-based, stateless protocol: each request stands on its own, and the server does not remember previous ones unless something like a cookie carries that state. That simplicity is why HTTP has scaled to the entire web.

Requests

A request has a method, a path, headers and sometimes a body.

POST /api/users HTTP/2
Host: example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer <token>

{ "name": "Ada" }

The method says what kind of action it is. The path identifies the resource. Headers carry metadata, and the body carries data for methods like POST and PUT.

Safe means it does not change state; idempotent means repeating it has the same effect as doing it once. These properties matter for caching, retries and proxies.

Responses and status codes

A response has a status code, headers and a body.

HTTP/2 201 Created
Content-Type: application/json
Location: /api/users/42

{ "id": 42, "name": "Ada" }

The status code tells the client what happened. Learn the common ones:

• 200 OK — success.
• 201 Created — a new resource was created.
• 204 No Content — success with no body.
• 301 / 302 — permanent and temporary redirects.
• 304 Not Modified — cached copy is still valid.
• 400 Bad Request — invalid input.
• 401 Unauthorized — not authenticated.
• 403 Forbidden — authenticated but not allowed.
• 404 Not Found — no such resource.
• 500 Internal Server Error — the server failed.

Returning the right code is not pedantry: clients, caches and monitoring all depend on it.

Headers

Headers are the metadata layer. Common request headers include Accept, Content-Type, Authorization, Cookie and User-Agent. Common response headers include Content-Type, Content-Length, Cache-Control, Set-Cookie and security headers such as Content-Security-Policy.

// fetch.js
const res = await fetch("/api/posts", {
  headers: {
    Accept: "application/json",
    Authorization: `Bearer ${token}`,
  },
});

Headers are how content negotiation, authentication, caching and security policies are expressed.

Cookies and sessions

HTTP is stateless, so servers use cookies to recognise returning users. The server sends Set-Cookie, and the browser sends that cookie back on subsequent requests to the same origin.

Session cookies should always be:

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/

• HttpOnly keeps JavaScript from reading it, which blunts XSS.
• Secure sends it only over HTTPS.
• SameSite limits cross-site sending, which helps prevent CSRF.

The Web Security guide covers the full picture.

Caching

Caching is the most valuable HTTP feature for performance. Two mechanisms work together:

• Freshness with Cache-Control, which sets how long a response may be reused.
• Validation with ETag or Last-Modified, which lets the client ask “has this changed?” and get a 304 Not Modified when it has not.

# versioned assets: cache for a year
Cache-Control: public, max-age=31536000, immutable

# HTML: revalidate every time
Cache-Control: no-cache

Fingerprint your assets with a content hash and cache them aggressively; a changed file gets a new name. Serve HTML with a short cache and revalidate so deploys are picked up.

HTTPS and TLS

HTTPS is HTTP over TLS. TLS does three things:

1. Encrypts the traffic so it cannot be read in transit.
2. Authenticates the server with a certificate.
3. Preserves integrity so data cannot be silently altered.

Obtain a certificate (free options exist), redirect all HTTP traffic to HTTPS, and enable HSTS to stop browsers from ever using plain HTTP for your domain. Treat HTTP as a legacy protocol.

HTTP versions

• HTTP/1.1 — one request at a time per connection, which is why sites used to concatenate files.
• HTTP/2 — multiplexes many requests over one connection and compresses headers, removing most of those hacks.
• HTTP/3 — runs over QUIC, a UDP-based transport, cutting connection latency and handling packet loss better.

Serving HTTPS usually enables HTTP/2 or HTTP/3 automatically through your server or CDN. You rarely need to change your code.

Best practices

• Use HTTPS everywhere and redirect HTTP to HTTPS with HSTS.
• Return precise status codes and meaningful error bodies.
• Keep methods safe and idempotent as their definitions require.
• Set Cache-Control and validators deliberately.
• Use HttpOnly, Secure, SameSite cookies for sessions.
• Set security headers such as CSP and X-Content-Type-Options.
• Prefer HTTP/2 or HTTP/3 and let the platform negotiate it.

Common mistakes

• Returning 200 for errors, which breaks clients and caches.
• Mutating data with GET, which is unsafe and can be cached or prefetched.
• Disabling caching for everything and hurting performance.
• Storing session tokens in localStorage instead of a cookie.
• Forgetting to redirect HTTP to HTTPS.
• Ignoring Content-Type and receiving parse errors.

Where to go next

HTTP is the shared language of the web, and fluency pays off everywhere. Build on the internet fundamentals, understand DNS, make requests from JavaScript with Fetch, and secure your traffic with the Web Security guide.