HTTP/HTTPS thumbnail

HTTP/HTTPS

⏱ approx. 12 min views 405 likes 0 LOG_DATE:2025-10-14
TOC

What HTTP/HTTPS is #

HTTP (Hypertext Transfer Protocol) is the text-based communication protocol used on the World Wide Web to exchange content — HTML, images, API responses — between web servers and web clients (browsers and the like). It runs on top of TCP (and on QUIC = UDP for HTTP/3), part of the TCP/IP suite.

HTTPS wraps the entire HTTP exchange in TLS (formerly SSL), defending against three threats at once: eavesdropping, tampering, and impersonation. Today essentially all Web traffic uses HTTPS, and browsers loudly warn users about mixed content or invalid certificates.

The shape of an HTTP exchange #

Client–server model #

HTTP is a stateless request/response protocol. A client sends a request, a server returns a response. One round trip is an HTTP transaction. The server does not, by itself, remember previous requests (it is stateless). State that must persist — login status, shopping carts — is layered on top with Cookies, sessions, or JWTs.

What an HTTP message looks like #

The wire format is plain text in HTTP/1.x: request/status line + headers + blank line + body. HTTP/2 and HTTP/3 keep the same logical structure but transmit it as binary frames.

Request example #

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,*/*
Cookie: session=abc123
  • Request line: method (GET) / path (/index.html) / protocol version (HTTP/1.1).
  • Headers: name: value pairs. Common: Host, User-Agent, Accept, Cookie, Authorization.
  • Blank line: separator between headers and body.
  • Body: payload for POST, PUT, etc. (form data, JSON, …).

Response example #

HTTP/1.1 200 OK
Date: Sun, 17 May 2026 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

<html>
...
</html>
  • Status line: protocol version / status code (200) / human-readable phrase (OK).
  • Headers: Content-Type, Content-Length, Set-Cookie, Cache-Control, etc.
  • Body: the actual content the client asked for.

HTTP methods #

Method Purpose Body Idempotent
GET Retrieve a resource No Yes
POST Create / arbitrary action Yes No
PUT Replace a resource Yes Yes
PATCH Partial update Yes No
DELETE Remove a resource Optional Yes
HEAD Headers only (like GET without body) No Yes
OPTIONS Ask what methods are allowed (used heavily for CORS preflight) No Yes

An idempotent method gives the same result no matter how many times you repeat it, so retries are safe. POST is not idempotent — guard against double submission in your design.

Status codes #

Three digits, where the leading digit classifies the response.

Class Meaning Examples
1xx Informational 100 Continue / 101 Switching Protocols
2xx Success 200 OK / 201 Created / 204 No Content
3xx Redirection 301 Moved Permanently / 302 Found / 304 Not Modified
4xx Client error 400 Bad Request / 401 Unauthorized / 403 Forbidden / 404 Not Found / 429 Too Many Requests
5xx Server error 500 Internal Server Error / 502 Bad Gateway / 503 Service Unavailable / 504 Gateway Timeout

401 and 403 are often confused. 401 means "you have not authenticated", while 403 means "you are authenticated but not allowed".

Important HTTP headers #

Only the security- and performance-relevant headers are listed here.

Request side

  • Host: virtual-host selector — one IP, many domains.
  • User-Agent: client identifier. WAFs and bot detection rely on it.
  • Cookie: previously issued cookies, re-sent on every request.
  • Authorization: credentials such as Basic … or Bearer <token>.
  • Referer: the URL of the previous page (yes, the spelling is wrong on purpose).

Response side

  • Set-Cookie: issue a cookie to the client.
  • Content-Type: MIME type (e.g. application/json; charset=UTF-8).
  • Cache-Control: how downstream caches should behave (no-store, max-age=3600, …).
  • Strict-Transport-Security (HSTS): force the client to use HTTPS for future visits.
  • Content-Security-Policy (CSP): restrict which sources may load scripts — a strong XSS mitigation.
  • X-Frame-Options / Content-Security-Policy: frame-ancestors: clickjacking defense.

Cookies and sessions #

HTTP itself is stateless, so login state and the like are carried in cookies. The server issues them with Set-Cookie, and the client echoes them back via the Cookie header.

To resist session hijacking, modern apps always set these attributes:

  • Secure — only sent over HTTPS.
  • HttpOnly — invisible to JavaScript (document.cookie); harder to steal via XSS.
  • SameSite=Lax / Strict — not sent on cross-origin requests; CSRF mitigation.
  • Expires / Max-Age — controls whether the cookie is session-scoped or persistent.

HTTP versions, generation by generation #

Version What's new
HTTP/1.0 (1996) One TCP connection per request — expensive.
HTTP/1.1 (1997) Keep-Alive for connection reuse; pipelining (rarely usable in practice).
HTTP/2 (2015) Binary framing; multiplexing — many parallel requests on one connection; header compression (HPACK).
HTTP/3 (2022) Runs on QUIC (UDP-based) for faster handshakes and no transport-level head-of-line blocking.

HTTP/2 partly fixed head-of-line blocking in HTTP/1.1, but only at the HTTP layer — TCP's in-order delivery still meant a single dropped packet stalled the entire connection. HTTP/3 fixes this fully by giving each stream its own ordering on top of UDP via QUIC.

Inside HTTPS #

HTTPS = HTTP + TLS (Transport Layer Security). TLS gives you three properties at once:

  1. Confidentiality — the conversation is opaque to anyone watching the wire.
  2. Integrity — message-authentication codes detect any tampering en route.
  3. Authenticity — the certificate proves the server is who it claims to be.

The TLS handshake (TLS 1.3, condensed) #

  1. Client Hello — the client lists the cipher suites it supports and sends a random nonce.
  2. Server Hello — the server picks one cipher suite, returns its certificate and public key.
  3. Key exchange — both sides derive a shared session key via Diffie–Hellman key agreement; passive eavesdroppers can't recover it.
  4. Finished — handshake done. From here on, traffic is encrypted with a symmetric cipher such as AES-GCM.

Four steps of the TLS 1.3 handshake

TLS 1.2 needed two round trips. TLS 1.3 brings this down to a single 1-RTT handshake (and 0-RTT when resuming an old session).

Certificates and the trust chain #

Server certificates are issued by Certificate Authorities (CAs). The client uses root CA public keys baked into the OS/browser to verify the chain (server certificate → intermediate CA → root CA), and completes the TLS handshake only if the chain validates.

CA-issued certificates come in three flavors:

  • DV (Domain Validation): only proves you control the domain. Let's Encrypt popularized free DV issuance.
  • OV (Organization Validation): also checks that the organization actually exists.
  • EV (Extended Validation): stricter identity vetting. The old green-bar UI was retired.

Security pitfalls #

Watch out for these as a server operator or developer.

  • Man-in-the-middle (MITM) — on public Wi-Fi, an attacker on the path sniffs or tampers with traffic. HTTPS plus correct certificate validation is the defense.
  • SSL stripping — the attacker blocks the HTTPS redirect and keeps the victim on plain HTTP. Returning HSTS (Strict-Transport-Security) forces future visits to HTTPS.
  • HSTS preloading — register your domain in the browser-shipped preload list to enforce HTTPS even on the very first visit.
  • Mixed content — an HTTPS page loading HTTP subresources (images, scripts) defeats the protection. The upgrade-insecure-requests CSP directive rewrites them automatically.
  • Insecure cookie attributes — missing Secure, HttpOnly, or SameSite opens the door to session hijacking, XSS data theft, and CSRF.
  • Certificate pinning risks — pin too tightly and a CA rotation will break your service. HTTP Public Key Pinning (HPKP) has been retired for exactly this reason.
  • TLS implementation bugs — Heartbleed (CVE-2014-0160) and friends. Keep OpenSSL up to date.

In penetration testing, Burp Suite and mitmproxy decrypt TLS by installing a local CA on the tester's machine. That's deliberately weakening certificate validation — never do that on production endpoints.