HTTP & HTTPS Explained: Methods, Status Codes and TLS

What an HTTP request looks like

HTTP is easy to read. Here is a real request:

POST /api/orders HTTP/1.1Host: shop.example.comContent-Type: application/jsonAuthorization: Bearer eyJhbGciOi...Content-Length: 33{"productId": 991, "quantity": 2}

• First line: the method (POST, the action), the path (/api/orders, the thing) and the HTTP version.
• Headers: extra information about the request, written as Key: Value pairs.
• Blank line, then the body (the data).

And the response:

HTTP/1.1 201 CreatedContent-Type: application/jsonLocation: /api/orders/5521{"id": 5521, "status": "pending"}

Try it yourself: curl -v https://example.com shows every line. (curl is a command-line tool that sends HTTP requests.)

HTTP methods

A resource is the thing a URL points to, such as a user or an order. Three properties of methods matter a lot in system design:

• Safe means the method does not change anything on the server. GET and HEAD are safe, so crawlers (programs that visit many pages) and caches can call them freely.
• Idempotent means doing it once or ten times gives the same final result. (Like pressing the "lift up" button in an elevator: pressing it again does nothing new.)
  • GET, PUT and DELETE are idempotent. Deleting item 3 twice still leaves item 3 deleted.
  • POST is not. Sending "create order" twice may create two orders.
• Cacheable means the response can be saved and reused later. GET responses usually are.

Why idempotency matters: networks fail. Say your app sends "pay ₹500" and the connection drops before the response arrives. Did the payment go through? If the request is idempotent, you can simply send it again. If it is a plain POST, sending it again might charge the customer twice. Companies like Stripe solve this with an idempotency key: a unique ID that you send with the request, so the server can see that a repeat is the same request. We cover this in a later lesson.

Status codes

A status code is a three-digit number in the response. The first digit tells you the category:

The ones you will use most:

• 200 OK: success.
• 201 Created: a new thing was created (often with a Location header pointing to it).
• 204 No Content: success, with nothing to return (common for DELETE).
• 301 Moved Permanently: the URL has changed for good. Browsers and search engines remember the new one.
• 302 Found / 307 Temporary Redirect: go there for now.
• 304 Not Modified: "your saved copy is still good", so no body needs to be sent. This saves a lot of bandwidth (the amount of data you can send).
• 400 Bad Request: the input is broken (bad JSON, missing field).
• 401 Unauthorized: "I do not know who you are". You need to log in. (The name is misleading: it is really about authentication, which means proving who you are.)
• 403 Forbidden: "I know who you are, but you are not allowed". (This is about authorization, which means what you are allowed to do.)
• 404 Not Found: no such thing.
• 409 Conflict: clashes with the current state (for example, that username is taken).
• 429 Too Many Requests: you hit a rate limit (a cap on how many requests you may send in a time). Slow down.
• 500 Internal Server Error: something unexpected went wrong in the server's code.
• 502 Bad Gateway: a proxy (a server that passes requests on for another server) or a load balancer got a bad answer from the server behind it.
• 503 Service Unavailable: overloaded or under maintenance. Try later.
• 504 Gateway Timeout: a proxy or load balancer waited too long for the server behind it.

When you debug problems on a live system, 502, 503 and 504 point to different problems:

• 502: the app crashed or returned garbage.
• 503: there are no healthy servers, or the app is overloaded.
• 504: the app is too slow.

Important headers

• Content-Type: what format the body is in (application/json, text/html).
• Authorization: who you are (a token or login details). A token is a secret string that proves your identity.
• Cache-Control: caching rules, for example max-age=3600 means "you can reuse this for 3,600 seconds (one hour)".
• ETag / If-None-Match: a fingerprint (a short code made from the content). The browser sends it back, and if nothing changed the server replies 304.
• Retry-After: sent with 429 or 503, tells the client when to try again.
• Location: where the new or redirected thing is.
• X-Forwarded-For: added by proxies and load balancers so the app knows the real client IP.

HTTP is stateless, and cookies add memory

Stateless means the server keeps no memory between requests. Each HTTP request stands alone. The server does not remember that you logged in a moment ago.

A cookie is a small piece of text that the browser stores and sends back to the server. It fixes this problem. The server sends Set-Cookie: session=abc123, and the browser sends Cookie: session=abc123 with every later request to that site. We look at sessions, cookies and tokens in more detail in the security series.

CORS in one paragraph

Browsers stop a web page on site-a.com from reading responses from api.site-b.com unless site-b clearly allows it. This rule is the same-origin policy. An origin is the combination of protocol, domain and port. The rule protects you from bad sites that try to read your bank data. CORS (Cross-Origin Resource Sharing) is how a server says "requests from site-a.com are OK", using headers like Access-Control-Allow-Origin. If you have built a React frontend and a separate API, you have probably seen a CORS error.

HTTP versions: 1.1, 2 and 3

HTTP/1.1 (1997)

• Text-based. A connection can be reused (keep-alive), but it handles one request at a time.
• Browsers open about 6 connections per site to get around this limit.
• Developers used tricks to need fewer requests, such as bundling all JS into one file and combining icons into one "sprite" image.

HTTP/2 (2015)

• Binary instead of text (computers read it faster, but people cannot read it directly).
• Multiplexing means sending many things at once over one path. Here, many requests and responses share one connection at the same time.
• Headers are made smaller (compressed) with a method called HPACK.
• The problem that remains: it still runs on TCP, so one lost packet blocks all the streams (this is TCP head-of-line blocking, from the last lesson).

HTTP/3 (2022)

• Runs on QUIC over UDP (QUIC is a modern protocol built on UDP, from the last lesson).
• A lost packet only delays the stream it belongs to.
• Faster connection setup, and better on mobile networks.

HTTPS and TLS

HTTPS = HTTP + TLS (Transport Layer Security). TLS is a protocol that protects a connection with encryption. It gives you three things:

1. Confidentiality. Nobody in the middle can read the data.
2. Integrity. Nobody can secretly change it on the way.
3. Authentication. You are really talking to yourbank.com, not a fake site.

Two kinds of encryption working together

• Symmetric encryption uses one shared secret key to lock and unlock the data (for example, AES). A key is a secret number used to scramble and unscramble data. Symmetric encryption is very fast. The problem: how do two strangers agree on a secret key over a public network?
• Asymmetric encryption uses a key pair: a public key (shared with everyone) and a private key (kept secret). It is slower, but it solves the "strangers" problem.

TLS uses asymmetric crypto during the handshake to safely agree on a key, then switches to fast symmetric encryption for the actual data.

Here is a comparison. Asymmetric encryption is like a padlock that anyone can snap shut but only the owner can open. You use it once to send a secret code safely. From then on, you both use that code to talk quickly. Difference in one line: symmetric uses one key and is fast, asymmetric uses two keys and is slow.

Certificates: proving who you are

How do you know the public key really belongs to yourbank.com? Through a certificate. A certificate is a digital ID card that says "this public key belongs to yourbank.com". It is signed by a trusted Certificate Authority (CA), a company that checks who owns a domain and vouches for it.

Your browser checks:

• Is this chain signed by a CA I trust?
• Has the certificate expired?
• Does it match the domain I typed?

If any check fails, you see a big warning page.

The TLS 1.3 handshake

• TLS 1.3 needs just one round trip (one trip to the server and back). The older TLS 1.2 needed two.
• On a repeat visit, TLS 1.3 can even send data immediately ("0-RTT"). But an attacker could copy and send that data again (a replay), so it should only be used for safe requests like GET.

Add it all up for a brand-new HTTPS connection over TCP: 1 round trip (TCP) + 1 round trip (TLS 1.3) + 1 round trip (HTTP request and response) = about 3 round trips before the first byte of the page. (This does not count the DNS lookup.) At 100 ms per round trip, that is 300 ms of pure waiting. This is why connection reuse, CDNs and HTTP/3 matter.

Where to "terminate" TLS

To terminate TLS means to decrypt the traffic at some point. In a real system, you choose where the encryption is removed:

• At the load balancer (most common). The load balancer (LB) decrypts the traffic, reads the HTTP (so it can route by URL), and forwards it to the app servers. This is simpler, and the certificates live in one place.
• Re-encrypt to the backend. The LB decrypts, then encrypts again before it sends the data to the app servers. This is safer inside your network and is often required in finance and healthcare.
• Passthrough. The LB does not decrypt at all; the app servers do. The downside is that the LB cannot see URLs or headers.

HSTS

Even with HTTPS, a user might type http://yourbank.com. That first plain-text request can be intercepted. HSTS (HTTP Strict Transport Security) is a response header that tells the browser: "for a set time (often a year), only use HTTPS for this site".