HyperText Transfer Protocol (HTTP)
HyperText Transfer Protocol (HTTP)
HyperText Transfer Protocol (HTTP): HTTP (HyperText Transfer Protocol) is an application-layer, stateless, client-server protocol used for communication over the web.
Client: Browser or API consumer
Server: Web server hosting the requested resource
Stateless: Each request is independent and does not retain memory of previous interactions
HTTP Communication Structure: Every HTTP interaction involves a request from the client and a response from the server.
HTTP Request: The general format of an HTTP request is:
Request Line – Contains: METHOD URI VERSION
Example: GET /index.html HTTP/1.1
Headers – Metadata like User-Agent, Accept, Authorization.
Host: www.example.com
Connection: Keep-Alive
Accept: image/gif, image/jpeg, */*
Accept-Language: en-us, fr, cn
Blank Line – Separates headers from the request body.
Message Body (Optional) – Contains data sent to the server.
HTTP Response: The general format of an HTTP response:
Status Line – Contains:
HTTP Version
Status Code (3-digit number)
Reason Phrase (short explanation)
HTTP/1.1 200 OK
HTTP/1.0 404 Not Found
HTTP/1.1 403 Forbidden
Response Headers – Provides additional information about the response.
Content-Type: text/html
Content-Length: 35
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
Blank Line – Separates headers from the response body.
Response Body – Contains the requested resource.
Common HTTP Status Codes: HTTP status codes are categorized as follows:
Category
Description
Examples
1xx
Informational
100 Continue, 101 Switching Protocols
2xx
Success
200 OK, 201 Created, 204 No Content
3xx
Redirection
301 Moved Permanently, 302 Found
4xx
Client Errors
400 Bad Request, 403 Forbidden, 404 Not Found
5xx
Server Errors
500 Internal Server Error, 502 Bad Gateway
503 Service Unavailable
HTTP Methods (Verbs): HTTP defines a set of request methods (or verbs) that indicate the action to be performed on a resource.
Safe Methods: GET, HEAD, OPTIONS (no server-side modifications).
Idempotent Methods: GET, HEAD, PUT, DELETE, OPTIONS, TRACE (repeating the request has the same effect as a single request).
Non-Idempotent: POST, PATCH (may change server state unpredictably on repetition).
Method
Description
GET
Retrieves data from a server (safe and idempotent).
HEAD
Similar to GET, but only fetches headers (no body).
POST
Sends data to the server (non-idempotent; may cause changes, e.g., form submissions).
PUT
Updates or replaces an existing resource (idempotent).
DELETE
Deletes the specified resource (idempotent).
CONNECT
Establishes a tunnel to a server (e.g., for HTTPS proxies).
OPTIONS
Returns communication options for the resource (e.g., CORS preflight).
TRACE
Performs a message loop-back test (rarely used; debugging only).
PATCH
Partially updates a resource (non-idempotent; modifies specific fields).
HTTP Headers
Headers allow clients and servers to pass additional information in HTTP requests and responses. Format: “Header-Name: Header-Value”
Types of HTTP Headers
General Headers – Apply to both requests and responses but do not relate to the actual data in the message body.
Connection, Date, Cache-Control.
Request Headers – Sent by the client to provide additional information about the request.
User-Agent: Identifies the client making the request.
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64)
Accept: Specifies the media types the client can handle.
Accept: text/html, application/json
Authorization: Sends credentials for authentication.
Authorization: Bearer <token>
Response Headers – Provides details about the response.
Server: Identifies the software running on the server.
Server: Apache/2.4.41 (Ubuntu)
Content-Type: Specifies the media type of the response.
Content-Type: application/json
Content-Length: Indicates the size of the response body in bytes.
Content-Length: 3482
Entity Headers – Provides details about the body of the request/response.
Describe the content characteristics of the response body.
Content-Encoding:
Specifies how the response is encoded
Content-Encoding: gzip
Content-Language:
Defines the natural language of the response.
Content-Language: en-US
Common Request Headers
Accept Headers: Negotiate content type, encoding, and language between client and server.
Accept – Specifies acceptable media types.
Accept: image/jpeg, */*
Accept-Charset – Specifies character encoding preference
Accept-Charset: utf-8
Accept-Encoding – Specifies compression encoding preference
Accept-Encoding: gzip, deflate
Accept-Language – Specifies preferred languages.
Accept-Language: en-US, fr
User-Agent – Identifies the client making the request
User-Agent: Mozilla/5.0
Common Response Headers
Content-Type – Specifies the type of content in the response.
Content-Type: text/html
Content-Length – Specifies the size of the response body
Content-Length: 35
Connection – Controls connection persistence.
Controls whether the network connection remains open after a transaction
keep-alive → Persistent connection (default in HTTP/1.1)
Example: Keep-Alive: timeout=5, max=1000
timeout: Time (seconds) connection should remain open
max: Maximum number of requests allowed on connection
close → Closes the connection after response.
Keep-Alive – Controls connection timeout settings
Used for persistent connections to specify timeout and max requests.
Keep-Alive: timeout=15, max=100
The q Parameter in Headers (Quality Factor)
Indicates preference ranking from 1.0 (highest) to 0.0 (lowest) when multiple values are specified. Example: q in Accept Header
Used by clients to specify which content types (MIME types) they prefer and their priority.
Accept: text/html, application/json;q=0.8, text/plain;q=0.6, */*;q=0.5
Client preferences: HTML preferred, then JSON (80% priority), plain text (60%), any type (50%)
HTTP Caching
HTTP caching helps reduce redundant data transfer and improves performance.
Cache-Control Header: Controls how caching is performed.
Request Cache-Control:
Cache-Control: no-cache (Revalidate with server before using cached copy)
Cache-Control: no-store (Never cache this content)
Response Cache-Control:
Cache-Control: must-revalidate (Strict cache validation required)
Cache-Control: public (Can be cached by shared caches/CDNs)
Cache-Control: private (Only user's browser can cache)
Expires Header: Specifies when the response expires.
Expires: Wed, 21 Oct 2025 07:28:00 GMT
ETag Header: Provides a unique identifier for a resource version for validation.
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
HTTP Redirection
Indicate that the requested resource has moved to another location.
301 Moved Permanently: The resource has been permanently relocated.
302 Found (Temporary Redirect): The resource has been temporarily relocated.
A redirection response includes the Location header:
Location: https://newsite.com/resource
HTTP Cookies
Cookies store small pieces of data on the client-side.
The Set-Cookie header sends a cookie from the server
Example: Set-Cookie: sessionId=abc123; HttpOnly
The Cookie header sends stored cookies with requests:
Example: Cookie: sessionId=abc123
Bidirectional and Asynchronous Communication
Modern web applications require real-time data exchange, which is achieved using:
AJAX (Asynchronous JavaScript and XML) –Update web page asynchronously
Fetch API – Promised-based HTTP requests
Webhooks – Used to notify other applications of changes.
Server-Sent Events (SSE): Sends real-time updates from the server to the client.
Polling – Periodically fetches data from the server.
WebSockets – Full-duplex, two-way connection between the client and server.
HTTP Versions
HTTP has evolved over time with multiple versions, each improving efficiency and functionality.
HTTP/1.x: Requires multiple connections for concurrency.
Problems:
Head-of-line blocking (one slow request blocks others).
No header compression (more network overhead).
Poor resource prioritization (inefficient TCP connection usage).
HTTP/2: Introduces header compression and multiplexing.
Multiplexing: Parallel requests in a single connection.
Header compression (HPACK)
Binary Protocol: Uses binary framing instead of text, making communication more efficient.
Server Push: Server can proactively send resources before requested
Reduces round trips by anticipating client needs
Example: Push CSS/JS files along with HTML
HTTP/3: Based on QUIC. Uses UDP instead of TCP which avoids TCP handshake delays..
Header compression (QPACK)
Solves TCP-based HoL blocking
Better performance on unstable networks
Reduced latency, optimized for mobile
Head-of-Line (HoL) Blocking: Head-of-Line (HoL) Blocking is a performance issue in networking where the first packet in a queue blocks the delivery of subsequent packets, leading to inefficiencies and delays.
HTTP/1.x HoL Blocking:
Problem: HTTP/1.1 uses pipelining, where multiple requests are sent on the same TCP connection sequentially.
If an earlier request is slow, all subsequent requests must wait, causing delays. Example:
A client requests:
Image A (slow response)
Image B
CSS file
If Image A takes too long, it blocks the delivery of Image B and CSS, even if they are ready.
HTTP/2 HoL Blocking
Introduced multiplexing on a single connection.
Allows multiple requests to be sent simultaneously without waiting for previous ones to complete.
However, HTTP/2 still experiences HoL blocking at the TCP level.
HoL Blocking in TCP
TCP ensures ordered delivery of data.
If one packet is lost, all subsequent packets must wait until it is retransmitted.
Even with HTTP/2 multiplexing, a single lost TCP packet can cause delays for multiple streams.
HTTP/3 (QUIC) and HoL Blocking
HTTP/3 uses QUIC instead of TCP.
QUIC allows independent streams over UDP, eliminating TCP-level HoL blocking.
Even if one stream has lost packets, others continue without waiting.
HTTP vs HTTPS
HTTP (Hypertext Transfer Protocol):
No encryption → Plain text
Port: 80
Vulnerable to attacks
HTTPS (Secure HTTP): Uses TLS/SSL to encrypt communication.
Mandatory for secure web apps (e.g., login, banking)
Protects data from interception (e.g., Man-in-the-Middle attacks).
Port 443 (instead of 80 for HTTP).
Uses TLS Handshake:
Agree on protocol version.
Select cryptographic algorithms.
Authenticate server via SSL/TLS certificate.
Establish shared encryption keys.
SSL/TLS Certificate:
Ensures secure identity verification.
Issued by Certificate Authorities (CA).
HTTPS Workflow:
Client Sends a Request: A user accesses a website via HTTPS, e.g., https://example.com.
Server Sends its SSL/TLS Certificate: The web server sends its SSL/TLS certificate, which includes:
Website domain name.
Public key.
Certificate Authority (CA) signature (proves certificate authenticity).
Expiration Date (certificates expire and must be renewed).
Certificate Verification: The browser verifies the certificate against a trusted Certificate Authority (CA).
If valid, the browser proceeds. If not, it shows a "Not Secure" warning.
TLS Handshake: The client and server perform a TLS handshake to establish a secure connection.
Steps in TLS Handshake:
Agree on TLS Version (e.g., TLS 1.3).
Select Encryption Algorithm (AES, ChaCha20, etc.).
Exchange Public Keys (using RSA, ECC, etc.).
Generate a Shared Secret Key (using Diffie-Hellman key exchange).
Start Encrypted Communication using symmetric encryption.
Secure Data Transmission: After the handshake, all communication is encrypted using the shared secret key. Data is protected from:
Man-in-the-Middle (MITM) attacks, Eavesdropping, Tampering.
HTTP Authentication Methods
Basic Authentication: Credentials (username:password) are Base64-encoded and sent in the Authorization header.
Authorization: Basic dXNlcjpwYXNz
Weak security - Base64 is easily reversible, and credentials can be intercepted if not encrypted via HTTPS.
Bearer Token Authentication (OAuth 2.0): Instead of credentials, the client sends a bearer token:
Authorization: Bearer <token>
Used in: REST APIs, SSO (Single Sign-On), OAuth flows.
Tokens are usually short-lived and scoped.
Digest Authentication: Sends a hashed version of the credentials.
More secure than Basic Auth but less common in modern web apps due to OAuth and token-based alternatives.
API Key Authentication: A unique key (static token) is sent in headers or query parameters.
x-api-key: YOUR_API_KEY
Used in: RESTful services, server-to-server communication.
HTTP Compression
Compression reduces payload/response size and improves speed.
Common Compression Methods: Gzip, Brotli (br), Deflate
The Client tells the server which compression methods are supported:
Accept-Encoding: gzip, br, deflate
The server responds with compressed data:
Content-Encoding: gzip
HTTP Proxies
Proxies act as intermediaries between clients and servers.
Forward Proxy: Acts on behalf of the client.
Reverse Proxy (e.g., Nginx): Acts on behalf of the server.
Type
Description
Forward Proxy
Client → Proxy → Server. Used for content filtering, caching, and security.
Reverse Proxy
Client → Reverse Proxy → Server. Handles load balancing, caching, SSL termination.
Transparent Proxy
Operates invisibly (e.g., corporate networks).
Anonymous Proxy
Hides user IP addresses for privacy.
HTTP CORS (Cross-Origin Resource Sharing)
CORS allows a frontend app to communicate with a server from a different origin (domain).
CORS Headers
Header
Purpose
Access-Control-Allow-Origin
Specifies allowed domains (e.g., example.com).
Access-Control-Allow-Methods
Lists permitted HTTP methods (e.g., GET, POST).
Access-Control-Allow-Headers
Defines allowed request headers (e.g., Content-Type).
Example: Allowing all origins
Access-Control-Allow-Origin: *
Example: Restricting to a specific domain
Access-Control-Allow-Origin: https://example.com
HTTP Load Balancing
Used to distribute traffic across multiple servers for performance and reliability.
Load Balancing Techniques
Round Robin: Requests are distributed evenly.
Least Connections: Requests go to the server with the fewest active connections.
IP Hashing: Directs users to the same server based on their IP address.
Geolocation-Based: Directs traffic based on users’ location.
Popular Load Balancers
Nginx, HAProxy, AWS Elastic Load Balancer (ELB), Cloudflare Load Balancing
HTTP in Microservices
Microservices communicate using HTTP APIs (usually RESTful or GraphQL).
Common Design Patterns
Pattern
Description
API Gateway
Single entry point for microservices.
Service Mesh
Manages HTTP-based service-to-service communication.
Rate Limiting
Restricts API requests to prevent abuse.
Circuit Breaker
Stops calls to failing services to avoid cascading failures.
HTTP Security Best Practices
Use HTTPS (SSL/TLS Encryption)
Use HTTP Strict Transport Security (HSTS) headers to enforce HTTPS on clients
Strict-Transport-Security: max-age=31536000; includeSubDomains
Prevents eavesdropping and MITM (Man-in-the-Middle) attacks.
Prevent Cross-Site Scripting (XSS)
Implement a strict Content-Security-Policy header to restrict which sources of scripts, styles, images, and other resources are allowed.
Content-Security-Policy: default-src 'self'
Prevent Clickjacking: Tricking users into clicking hidden elements.
Use the X-Frame-Options header to control whether your site can be framed by other sites.
X-Frame-Options: DENY
Set Secure Cookies: Use the Secure flag to ensure cookies are only sent over HTTPS.
Use the HttpOnly flag to prevent JavaScript access to cookies, mitigating the risk of theft via XSS.
Use the SameSite attribute (Lax or Strict) to restrict cross-site cookie sending and reduce CSRF risks
Set-Cookie: sessionId=abc123; Secure; HttpOnly
Implement Rate Limiting: Limit the number of requests per IP or user within a time window to prevent brute-force attacks and Denial-of-Service (DoS) attacks.
Common Attacks & Prevention:
Eavesdropping: Unauthorized interception and passive listening to data transmitted over a network.
Goal: To secretly capture sensitive information such as passwords, credit card numbers, or personal data without altering it.
Man-in-the-Middle (MITM) Attack: An active attack where the attacker secretly intercepts and possibly alters the communication between two parties who believe they are directly communicating.
Communication Methods
Synchronous vs. Asynchronous Communication
Synchronous: Client waits for a response before proceeding.
Blocking operation
Simple to implement but poor user experience
Example: Traditional form submission
Asynchronous: Client sends a request and continues execution while waiting for the response.
Non-blocking operation
Better user experience
Implemented via callbacks, promises, async/await
Example: AJAX requests
Long-Running Transactions: Some API tasks (e.g., file processing, machine learning jobs) take longer than the typical HTTP request timeout.
Approach: 202 Accepted Response: The server immediately responds with 202 Accepted, indicating that the request is being processed.
The client must poll the server periodically to check for completion.
Communication with Backend
AJAX (Asynchronous JavaScript and XML): Used for making asynchronous HTTP requests.
Fetch API: Modern alternative to XMLHttpRequest.
Webhooks: Server-side event-driven callbacks.
Eliminates need for polling
Requires client to have public endpoint
Good for event notifications
Security considerations (authentication, validation)
Implementation:
Client registers callback URL with server
Server POSTs to URL when event occurs
Client processes incoming webhook
Server-Sent Events (SSE): One-way data push from server to client.
Text-based protocol over HTTP
Content-Type: text/event-stream
Polling: The client periodically requests the server for updates.
Simple Polling: Client repeatedly requests server at fixed intervals
Simple but inefficient (many empty responses)
Long Polling: Server holds request until data available
Reduces empty responses but ties up resources
Best Practices:
Use 202 Accepted for long-running operations
Include Location header with status URL
Set Retry-After header to control polling frequency
WebSockets: Full-duplex, bidirectional communication over single TCP connection
Low latency
Efficient for high-frequency messages
Approaches for Real-Time Updates
Method
Direction
Best For
Limitations
Polling
Client → Server
Simple periodic updates
Inefficient; redundant requests.
Webhooks
Server → Client
Event-driven notifications
Requires public callback URL.
SSE
Server → Client
Unidirectional live updates
No bidirectional support.
WebSockets
Bi-directional
Full-duplex real-time communication
Requires persistent TCP connection.
Calling APIs from the Frontend: Traditionally, browsers fetch data synchronously, requiring a full page reload. AJAX (Asynchronous JavaScript and XML) allows web applications to update content dynamically without reloading the page.
Fetch API: The Fetch API is a modern way to make network requests in JavaScript.
Cleaner syntax than XHR
Returns a Promise that resolves to a Response object.
Supports various HTTP methods (GET, POST, PUT, DELETE).
Example:
fetch(url, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(data) });
Axios (Alternative to Fetch API): Axios is a Promise-based HTTP client with added features.
Advantages over Fetch API:
Automatic JSON parsing (Fetch requires .json() call).
Built-in timeout support (Fetch does not support timeouts).
Request and response interceptors.
Example:
axios.get('https://api.example.com/data')
.then(response => console.log(response.data))
.catch(error => console.error(error));
Last updated