HTTP & TLS
HTTP versions, headers, methods and status codes, virtual hosts and SNI, the TLS handshake, HSTS and mutual TLS, and reading a failing curl.
11 questions
JuniorTheoryVery commonWhat happens during a TLS handshake, and what does certificate validation check?
What happens during a TLS handshake, and what does certificate validation check?
The client sends a hello with its ciphers and hostname (SNI); the server replies with its certificate; both derive a session key and switch to encryption. Validating the cert, the client checks three things: it chains to a trusted root CA, the hostname matches its SAN, and it is unexpired.
Common mistakes
- ✗Thinking the server sends its private key during the handshake
- ✗Believing validation checks only expiry, not chain and hostname
- ✗Assuming SNI is sent encrypted rather than in the opening hello
Follow-up questions
- →Why must the hostname match the certificate's SAN rather than its CN today?
- →What breaks if the server omits an intermediate certificate from the chain?
JuniorTheoryCommonWhich HTTP request and response headers matter most to an operator?
Which HTTP request and response headers matter most to an operator?
Host routes to the right virtual host; Content-Type states the body format; Cache-Control and ETag drive caching and revalidation; Connection controls keep-alive. Behind a reverse proxy, X-Forwarded-For and X-Forwarded-Proto carry the real client IP and scheme the backend would otherwise miss.
Common mistakes
- ✗Swapping the roles of
HostandContent-Type - ✗Assuming the backend sees the real client IP without
X-Forwarded-For - ✗Thinking
Connection: closeenables keep-alive rather than ending it
Follow-up questions
- →Why can trusting
X-Forwarded-Forfrom any source be a security problem? - →How do
ETagandIf-None-Matchproduce a 304 Not Modified?
JuniorTheoryCommonWhich HTTP methods are safe and which are idempotent — GET, POST, PUT, DELETE?
Which HTTP methods are safe and which are idempotent — GET, POST, PUT, DELETE?
Safe methods do not change server state: GET and HEAD. Idempotent methods give the same result sent once or repeated: GET, HEAD, PUT and DELETE. POST is neither — repeating it can create a second resource or charge twice. So a proxy or client may retry a GET or PUT but not a POST.
Common mistakes
- ✗Calling POST idempotent because it often succeeds twice
- ✗Thinking safe and idempotent are the same property
- ✗Believing DELETE is not idempotent because a repeat may 404
Follow-up questions
- →Why is
DELETEidempotent even though a repeat may return 404? - →How does idempotency let a load balancer safely retry a request?
JuniorTheoryCommonWhat do the HTTP status classes 2xx/3xx/4xx/5xx mean — an example of each?
What do the HTTP status classes 2xx/3xx/4xx/5xx mean — an example of each?
The leading digit names the class: 2xx success (200), 3xx redirect (301 permanent vs 302 temporary), 4xx client error you must fix the request (404, 401 unauthenticated vs 403 forbidden, 429 too many requests), 5xx server fault (500). The class alone tells you whose side the problem is on.
Common mistakes
- ✗Swapping 4xx (client) and 5xx (server) responsibility
- ✗Treating 401 (unauthenticated) and 403 (forbidden) as the same
- ✗Confusing 301 (permanent) with 302 (temporary) redirects
Follow-up questions
- →Why does a 301 get cached by browsers while a 302 usually is not?
- →When would an API return 403 rather than 401 for the same request?
MiddleTheoryCommonWhat is mutual TLS, and when would you use it?
What is mutual TLS, and when would you use it?
Normal TLS authenticates only the server. In mutual TLS (mTLS) the client also presents a certificate, so both sides authenticate each other. Use it for service-to-service traffic with no human login — internal services or a mesh — often terminated at a gateway that re-encrypts to the backend.
Common mistakes
- ✗Thinking mTLS only strengthens the cipher rather than adding client auth
- ✗Applying mTLS to ordinary browser traffic with no client cert
- ✗Assuming mTLS can never be terminated at a gateway
Follow-up questions
- →How does a service mesh issue and rotate mTLS certificates automatically?
- →What is the difference between TLS termination and TLS passthrough at a load balancer?
MiddleTheoryCommonWhat is a certificate chain, and how does a client verify trust up to a root CA?
What is a certificate chain, and how does a client verify trust up to a root CA?
A server's leaf cert is signed by an intermediate Certificate Authority (CA), itself signed by a root CA the client trusts — a chain of signatures. The client verifies each signature to a trusted root and checks dates. The server must send the intermediates, or clients lacking them cannot complete the chain.
Common mistakes
- ✗Thinking the server sends only the leaf and clients fetch the rest
- ✗Believing a self-signed leaf is trusted without any chain
- ✗Forgetting a missing intermediate breaks validation for many clients
Follow-up questions
- →Why do some browsers succeed while others fail with a missing intermediate?
- →How does
openssl s_client -showcertsreveal an incomplete chain?
JuniorTheoryOccasionalHow do HTTP/1.0, 1.1, 2 and 3 differ — keep-alive, multiplexing, QUIC?
How do HTTP/1.0, 1.1, 2 and 3 differ — keep-alive, multiplexing, QUIC?
HTTP/1.0 opened a new TCP connection per request. 1.1 added persistent keep-alive but returns replies in order, so one slow reply blocks the rest — head-of-line blocking. HTTP/2 multiplexes many streams over one connection; HTTP/3 runs over QUIC on UDP, ending transport-level head-of-line blocking.
Common mistakes
- ✗Thinking HTTP/2 opens many connections rather than multiplexing one
- ✗Believing keep-alive existed in 1.0, or that 1.1 multiplexes streams
- ✗Assuming HTTP/3 still runs on TCP rather than QUIC over UDP
Follow-up questions
- →Why does HTTP/2 multiplexing not remove TCP-level head-of-line blocking?
- →What does reusing a keep-alive connection save on each request?
JuniorTheoryOccasionalWhat is a virtual host, and how does one IP serve many different sites?
What is a virtual host, and how does one IP serve many different sites?
A virtual host lets one server (one IP and port) serve many sites by choosing from the request's Host header — name-based hosting. It matches the hostname to a config block and serves that site. Over HTTPS the choice comes earlier, from the TLS SNI field, before the cert is sent.
Common mistakes
- ✗Thinking each site needs its own dedicated IP address
- ✗Believing the
Hostheader is optional with many sites on one IP - ✗Forgetting HTTPS selects the site via SNI before decryption
Follow-up questions
- →Why is the
Hostheader mandatory in HTTP/1.1 but not 1.0? - →How does SNI expose the requested hostname before encryption begins?
MiddleDebuggingOccasionalA reverse proxy is throwing 502/503/504 in bursts — diagnose and fix it
A reverse proxy is throwing 502/503/504 in bursts — diagnose and fix it
Each code is a different upstream fault. 502 Bad Gateway — the upstream replied invalidly or refused the connection (crashed or wrong port). 504 Gateway Timeout — the upstream accepted but missed the proxy timeout (slow or overloaded). 503 — no healthy backend. Fix per cause: repair the backend, the timeout, or the health check.
Open full question →Common mistakes
- ✗Confusing 502 (bad reply) with 504 (upstream timeout)
- ✗Restarting the proxy when the fault is in the upstream
- ✗Treating 503 as a client error rather than no healthy backend
Follow-up questions
- →Which proxy setting most often causes a 504 under load?
- →How does a misconfigured health check produce a 503 with healthy pods?
MiddleTheoryOccasionalWhat is HSTS, and which attack does it prevent?
What is HSTS, and which attack does it prevent?
HSTS (HTTP Strict Transport Security) is the Strict-Transport-Security response header telling the browser to use HTTPS only for a domain for a set max-age. After the first visit the browser refuses plain HTTP and upgrades requests itself, preventing SSL-stripping — a man-in-the-middle downgrade to plain HTTP.
Common mistakes
- ✗Thinking HSTS itself encrypts traffic rather than enforcing HTTPS
- ✗Believing it protects the very first visit without preloading
- ✗Calling it a request header instead of a response header
Follow-up questions
- →Why does the HSTS preload list matter for the first-ever visit?
- →What are the risks of setting a very long
max-ageduring rollout?
MiddleDebuggingOccasionalHTTPS returns the wrong site's certificate — diagnose the SNI mismatch
HTTPS returns the wrong site's certificate — diagnose the SNI mismatch
Many HTTPS sites share one IP and port, so the server picks the certificate from the TLS SNI field (the hostname in the client hello). A request with no SNI (old client, raw-IP) gets the default vhost's certificate, so only those clients see the mismatch. Fix: ensure SNI is sent, and make the intended site the default server block.
Open full question →Common mistakes
- ✗Blaming DNS or an expired cert instead of SNI-based selection
- ✗Assuming one IP forces a single shared certificate for all sites
- ✗Forgetting SNI-less clients fall back to the default virtual host
Follow-up questions
- →Why can a raw-IP or very old client trigger this while browsers do not?
- →How does the server's default server block change the fallback certificate?
