0003 - HTTP and HTTPS

Basic Concepts: HTTP (Hypertext Transfer Protocol)

• What is it? An application-layer protocol for transmitting hypermedia documents, such as HTML. It’s the foundation of data communication for the World Wide Web.
• Client-Server Model: HTTP is a request-response protocol. The client (e.g., browser) sends an HTTP Request, and the server (e.g., web server) returns an HTTP Response.
• Stateless: Each HTTP request is an independent transaction. The server does not retain any state between requests from the same client. (State is managed at the application level using sessions, tokens, etc.).

Anatomy of an HTTP Request/Response

Request:

1. Request Line: GET /users/123 HTTP/1.1 (Method, URI, HTTP Version).
2. Headers: Key-value pairs with metadata (Host: api.example.com, Authorization: Bearer …, Content-Type: application/json).
3. Blank Line: Separates headers from the body.
4. Body (Optional): The payload of the request (e.g., JSON for a POST request).

Response:

1. Status Line: HTTP/1.1 200 OK (HTTP Version, Status Code, Status Message).
2. Headers: Content-Type: application/json, Content-Length: 150, Cache-Control: no-cache.
3. Blank Line.
4. Body (Optional): The content requested (e.g., HTML page, JSON data).

Common HTTP Methods & Idempotency

Idempotent means that making the same request multiple times has the same effect as making it once.

• GET: Retrieves a resource. It is safe (should not alter server state) and idempotent.
• POST: Submits a new entity. It is not idempotent. (Sending the same POST twice will create two new resources).
• PUT: Replaces a target resource with the request payload. It is idempotent. (Sending the same PUT request twice to update a user’s email will result in the same final state).
• PATCH: Applies partial modifications to a resource. It is not idempotent (e.g., a PATCH to increment a value).
• DELETE: Deletes a specified resource. It is idempotent. (Deleting the same resource twice has the same result—the resource is gone).

Advanced Concepts: HTTPS (HTTP Secure)

• What is it? It’s not a separate protocol. It is HTTP layered on top of SSL/TLS (Secure Sockets Layer/Transport Layer Security). The ‘S’ stands for secure, and it means the connection is encrypted.
• Why is it needed? Without HTTPS, anyone on the network (e.g., on public Wi-Fi) can intercept and read your HTTP traffic in plaintext. HTTPS provides:

1. Encryption: Protects the data from being eavesdropped on.
2. Authentication: Verifies that you are talking to the correct server (prevents man-in-the-middle attacks).
3. Integrity: Ensures that the data has not been tampered with in transit.

The TLS Handshake (Simplified for Interviews)

1. Client Hello: The client sends a message to the server, including the TLS versions it supports and a list of supported cipher suites (encryption algorithms).
2. Server Hello: The server responds, choosing a TLS version and cipher suite from the client’s list.
3. Server Certificate: The server presents its SSL certificate to the client. This certificate contains the server’s public key and is signed by a trusted Certificate Authority (CA). The browser checks if it trusts the CA.
4. Key Exchange: The client and server use the public/private key pair (asymmetric encryption) to securely negotiate a symmetric session key. This is the key that will be used to encrypt all the actual HTTP data for the rest of the session.
5. Secure Communication: All subsequent HTTP traffic is encrypted using this shared symmetric key, which is much faster than asymmetric encryption.

• HTTP/2 and HTTP/3:
  • HTTP/2: A major revision that introduced multiplexing, allowing multiple requests and responses to be sent over a single TCP connection simultaneously. This solves the “head-of-line blocking” problem at the HTTP level.
  • HTTP/3: The newest version, which runs over QUIC (a protocol built on UDP). This solves the head-of-line blocking problem at the transport layer, as a lost UDP packet doesn’t block other streams on the same connection.