HTTP vs HTTPS: Methods, Status Codes and TLS Handshake

HTTP is the protocol of the web: every page, image, script and API call your browser makes is an HTTP request answered by an HTTP response. It is simple on purpose (text messages in its classic form, one request and one response) and stateless, which is what lets it scale to billions of users. HTTPS is not a different protocol; it is HTTP sent through an encrypted TLS tunnel. This note covers the message format, methods, status codes, state, the three HTTP versions and the TLS handshake.

How HTTP works

HTTP is a client-server, request-response protocol at the application layer. The client (a browser, an app, curl) opens a connection to the server, sends a request and reads the response. HTTP/1.1 and HTTP/2 run over TCP; HTTP/3 runs over QUIC on UDP. The resource is named by a URL:

The request and the response

A request has a request line (method, path, version), headers, a blank line and an optional body. A response has the same shape with a status line (version, status code, reason phrase) in front.

1. The request: a request line with the method, the path and the version, then headers one per line, then a blank line, then the body. Content-Length tells the server where the body ends: these 42 bytes.
2. The response has the same shape with a status line in front: the version, the status code 201 and its reason phrase. Location names the user just created, and the body is 50 bytes.

Content-Length is the body's size in bytes, which is how the reader knows where the body ends. In HTTP/2 and HTTP/3 the same fields travel as binary frames, but the meaning is identical.

HTTP methods

A method is safe if it does not change server state, and idempotent if sending it once or many times leaves the server in the same state.

Idempotence is about state, not the response: a second DELETE of the same item may return 404, but the server is in the same state as after the first. This is why clients and proxies may retry idempotent requests after a network failure but must not blindly retry a POST.

Status codes

The pairs interviewers ask about:

• 401 vs 403: 401 means "authenticate first"; 403 means "you are known, and still not allowed".
• 301 vs 302: 301 is permanent (browsers and search engines remember the new URL), 302 is temporary. 307 and 308 are their counterparts that forbid changing the method, so a redirected POST stays a POST.
• 502 vs 504: both come from a gateway or proxy; 502 means the upstream server sent an invalid response, 504 means it did not answer in time.
• 304 Not Modified: the client's cached copy is still valid, so no body is sent.

Headers

Statelessness, cookies and sessions

HTTP itself remembers nothing between requests. To keep a user logged in, the server sends a cookie, and the browser returns it on every later request to that site.

1. The login request succeeds. The server stores the user under a random session ID, 4f2a9c, and sends that ID back in a Set-Cookie header; the browser files the cookie under this site.
2. Later, a completely separate request: HTTP itself remembers nothing of the login. But the browser attaches the cookie automatically to every request it sends to this site.
3. The server looks the ID up, finds Asha, and answers as if the conversation had continued. A request with an unknown ID, such as session=000000, would get 401 Unauthorized.

A real Set-Cookie header also carries attributes that limit where and how the cookie travels:

Set-Cookie: session=4f2a9c; Path=/; Max-Age=86400; HttpOnly; Secure; SameSite=Lax

With a server-side session, as in the figure, the cookie holds only a random ID and the server keeps the user's data in memory, a database or a cache such as Redis. With token-based authentication, the client holds a signed token (such as a JWT) carrying the user's identity, and the server only verifies the signature. Sessions are easy to revoke; tokens need no lookup but are harder to cancel before they expire.

HTTP/1.1 vs HTTP/2 vs HTTP/3

1. HTTP/1.1 on one connection: a request goes out only after the previous response has fully arrived, and each costs a round trip plus the server's time. The slow app.js holds up logo.png behind it; all three are in at 300 ms.
2. HTTP/2 sends all three requests at once and interleaves the responses as frames on one connection. While app.js is still being generated, the CSS and the image flow past it, and everything is in at 140 ms.

HTTP/1.0 (1996) opened a new connection for every request. HTTP/1.1 made persistent connections the default and added the mandatory Host header (so many sites can share one IP address) and chunked transfer. Its pipelining feature allowed several requests in a row, but responses had to come back in order and browsers left it switched off. HTTP/2's server push was later dropped by browsers. HTTP/3 also survives a change of network, such as Wi-Fi to mobile data, because QUIC identifies a connection by an ID rather than by IP addresses and ports.

HTTPS and the TLS handshake

HTTPS gives three guarantees: confidentiality (nobody on the path can read the data), integrity (any change is detected) and authentication (a certificate proves the server owns the domain). TLS 1.3 sets all three up in one round trip after TCP's:

1. TCP first: SYN and SYN-ACK cost one round trip, so the client's clock reads 50 ms before any TLS message has been sent.
2. The client's ACK goes out with the ClientHello right behind it: the versions and ciphers it supports, its Diffie-Hellman key share and the server name it wants (SNI).
3. The server answers with its own key share. Both sides can now compute the same secret, so everything after the ServerHello is encrypted: the certificate, a signature proving the server holds its private key, and Finished. That is round trip 2, at 100 ms.
4. The client checks the certificate chain, dates and host name and the signature, sends its own Finished, and puts the first HTTP request on the same flight, already encrypted.
5. The response's first byte arrives after 3 round trips, 150 ms. TLS 1.2 needed a second handshake round trip, so the same request took 200 ms; on a reused connection only the last round trip remains.

The two key shares are the halves of an ephemeral Diffie-Hellman exchange: each side combines its own private value with the other's share and arrives at the same shared secret, from which both derive the session keys, without the secret ever crossing the network. The certificate check is what stops an impostor: the chain must lead to a certificate authority the client trusts, the dates must be valid, the names must cover the requested host and it must not be revoked, and the CertificateVerify signature proves the server holds the matching private key. Application data then flows under a fast symmetric cipher such as AES-GCM or ChaCha20-Poly1305.

TLS 1.2 needed two round trips and also allowed RSA key exchange, where the client encrypts a secret with the server's public key. That lacks forward secrecy: anyone who later steals the server's private key can decrypt recorded traffic. TLS 1.3 removed it; every key exchange is ephemeral. Asymmetric cryptography is used only to agree keys and prove identity, because it is far slower than symmetric encryption; see network security basics.

Worked example: round trips before the first response byte

Take a round-trip time of 50 ms and ignore DNS and server processing time.

On a reused connection only the last round trip remains, which is why keep-alive and connection reuse matter so much.

HTTPS does not hide everything: the IP addresses, the timing and size of traffic, the DNS lookup and normally the server name in the ClientHello (unless Encrypted Client Hello is used) are visible. The path, query string, headers, cookies and body are encrypted.

REST basics

REST (Representational State Transfer) is a style for designing APIs on top of HTTP: resources are named by URLs (nouns), HTTP methods are the verbs, each request carries everything needed to process it (stateless), and resources are transferred as representations, usually JSON.

Common mistakes

• Saying GET is secure because parameters are "hidden" in POST: both are readable over HTTP and both are encrypted over HTTPS; GET parameters do end up in logs and history.
• Calling PATCH idempotent by definition: only GET, HEAD, OPTIONS, PUT and DELETE (and TRACE) are.
• Treating 401 and 403 as the same.
• Saying HTTPS encrypts the domain name: DNS and SNI normally reveal it.
• Saying HTTP/2 removed head-of-line blocking completely: it remains at the TCP level; HTTP/3 removes it.
• Describing the TLS handshake as "the client encrypts the data with the server's public key": the public key authenticates and helps agree a symmetric key; the data is encrypted symmetrically.

Interview questions

What is idempotency, and which HTTP methods are idempotent? A request is idempotent if repeating it leaves the server in the same state as sending it once. GET, HEAD, OPTIONS, PUT and DELETE are idempotent; POST is not, and PATCH is not guaranteed to be. It matters because idempotent requests can be retried safely after a timeout.

How do cookies make a stateless protocol stateful? The server sends a Set-Cookie header with an identifier, and the browser automatically includes it in every later request to that site. The server uses the identifier to look up the session, so a sequence of independent requests behaves like one logged-in conversation.

What did HTTP/2 improve over HTTP/1.1? It replaced text with binary framing and multiplexes many concurrent streams over a single TCP connection, so one slow response no longer blocks the others at the HTTP level and browsers need fewer connections. It also compresses headers with HPACK, saving bytes on repeated headers such as cookies.

Why does HTTP/3 run on UDP? TCP delivers bytes strictly in order, so a single lost packet stalls every HTTP/2 stream sharing the connection. QUIC, built on UDP, implements reliability per stream, so a loss affects only its own stream. It also merges the transport and TLS handshakes and can move a connection between networks.

Explain the TLS handshake. The client and server exchange supported versions, random numbers and Diffie-Hellman key shares, and both compute the same secret from which session keys are derived. The server proves its identity with its certificate and a signature made with the matching private key, both sides confirm the handshake with Finished messages, and the data then flows under symmetric encryption.

What does a certificate prove, and how does a browser check it? It binds a public key to a domain name, signed by a certificate authority. The browser follows the chain of signatures up to a root certificate in its trust store, checks the validity dates, checks that the certificate's names match the host and checks revocation; then the server must prove it holds the private key.

What is the difference between 502 and 504? Both are returned by a gateway, proxy or load balancer. 502 Bad Gateway means the upstream server returned an invalid or broken response; 504 Gateway Timeout means the upstream server did not respond within the proxy's time limit.

Next, read routing and routing protocols, and test yourself with the Computer Networks (Intermediate) skill test.