HTTP and HTTPS Protocol: A Complete Guide to Web Communication

Deep dive into HTTP methods, status codes, headers, keep-alive, and protocol evolution. Understand HTTP/1.1, HTTP/2, and HTTP/3 differences.

published: March 22, 2026 reading time: 13 min read

HTTP and HTTPS Protocol: A Complete Guide to Web Communication

Every time you browse the web, HTTP handles the conversation between your browser and servers. Understanding how HTTP works helps you debug issues, design better APIs, and appreciate why modern protocols evolved the way they did.

This post covers the fundamentals of HTTP and HTTPS, including methods, status codes, headers, and the evolution from HTTP/1.1 to HTTP/3. If you want to understand TLS and security, the SSL/TLS and HTTPS post covers that separately.

What is HTTP?

HTTP (Hypertext Transfer Protocol) is a request-response protocol. The client sends a request, the server sends a response. That is the core model.

HTTP is stateless. Each request stands alone. The server does not remember previous requests from the same client unless you add session management on top.

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: GET /index.html HTTP/1.1
    Client->>Server: Host: example.com
    Client->>Server: Accept: text/html
    Server->>Client: HTTP/1.1 200 OK
    Server->>Client: Content-Type: text/html
    Server->>Client: Content-Length: 1256
    Server->>Client: <html>...</html>

The protocol has evolved through several versions. HTTP/1.1 remains widespread, but HTTP/2 and HTTP/3 offer real performance gains.

HTTP Methods

HTTP defines several methods (also called verbs) that indicate the desired action:

GET

Retrieves data. GET requests should be safe and idempotent. Safe means they do not modify server state. Idempotent means multiple identical requests have the same effect as one.

GET /api/users HTTP/1.1
Host: example.com

POST

Submits data to be processed. POST requests typically cause state changes on the server.

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{"name": "Alice", "email": "alice@example.com"}

PUT

Replaces a resource at a specific URL. If the resource exists, it is updated. If it does not exist, it is created.

PUT /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json

{"name": "Alice", "email": "alice.new@example.com"}

PATCH

Partially updates a resource. Unlike PUT which replaces the whole resource, PATCH updates only the specified fields.

PATCH /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json

{"email": "alice.updated@example.com"}

DELETE

Removes a resource.

DELETE /api/users/123 HTTP/1.1
Host: example.com

Other Methods

Method	Purpose	Safe	Idempotent
HEAD	Like GET but returns only headers	Yes	Yes
OPTIONS	Returns supported methods for a URL	Yes	Yes
CONNECT	Converts to a tunnel (used for proxies)	No	No
TRACE	Echoes the request (for debugging)	Yes	Yes

HTTP Status Codes

Status codes tell you what happened with the request. They are grouped by range:

1xx: Informational

The request was received, continuing process.

HTTP/1.1 100 Continue

100 Continue means the client should send the request body. This is useful when sending large requests to check if the server will accept them first.

2xx: Success

The request was successfully received, understood, and accepted.

Code	Meaning
200	OK - Standard success response
201	Created - Resource was created
204	No Content - Success with no response body

3xx: Redirection

Further action needed to complete the request.

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

Code	Meaning
301	Moved Permanently - Resource now at new URL
302	Found - Temporary redirect
304	Not Modified - Cached version is still valid

301 and 302 are the most common redirects. The difference matters for SEO: 301 tells search engines the move is permanent.

4xx: Client Errors

The request has bad syntax or cannot be fulfilled.

HTTP/1.1 404 Not Found

Code	Meaning
400	Bad Request - Malformed syntax
401	Unauthorized - Authentication required
403	Forbidden - Authenticated but not authorized
404	Not Found - Resource does not exist
429	Too Many Requests - Rate limited

5xx: Server Errors

The server failed to fulfill a valid request.

Code	Meaning
500	Internal Server Error - Something broke on the server
502	Bad Gateway - Upstream server returned error
503	Service Unavailable - Server is temporarily overloaded
504	Gateway Timeout - Upstream server took too long

HTTP Headers

Headers provide metadata about the request or response. They are essential for caching, authentication, content negotiation, and more.

Common Request Headers

GET /api/data HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Header	Purpose
Host	Domain name of the server
Accept	Media types the client can handle
Authorization	Credentials for authentication
Cache-Control	Caching directives
User-Agent	Client application information
Cookie	Session data previously set by server

Common Response Headers

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 512
Cache-Control: max-age=3600
Set-Cookie: session=abc123; HttpOnly; Secure
X-Request-ID: req-12345

Header	Purpose
Content-Type	Media type of the response
Content-Length	Size of the response body
Cache-Control	Caching directives for clients
Set-Cookie	Data to store on the client
ETag	Version identifier for caching
X-Request-ID	Unique request identifier

Keep-Alive and Connection Management

HTTP/1.0 closed the connection after each request by default. HTTP/1.1 introduced persistent connections.

With Keep-Alive, multiple requests can reuse the same TCP connection:

# Without Keep-Alive: 3 TCP connections for 3 requests
GET /page1.html -> TCP connection 1 -> close
GET /page2.html -> TCP connection 2 -> close
GET /page3.html -> TCP connection 3 -> close

# With Keep-Alive: 1 TCP connection for 3 requests
GET /page1.html -> TCP connection 1
GET /page2.html -> TCP connection 1 (reused)
GET /page3.html -> TCP connection 1 (reused)
Connection: close -> close

Keep-Alive reduces latency by avoiding TCP handshake overhead. It also reduces server load by needing fewer connections.

# Request with Keep-Alive
GET /api/data HTTP/1.1
Host: example.com
Connection: keep-alive

# After response, connection stays open for more requests

HTTP/2: Multiplexing

HTTP/1.1 improved with persistent connections, but requests still had to complete in order (head-of-line blocking). HTTP/2 introduced multiplexing.

With multiplexing, multiple requests and responses flow simultaneously over a single connection:

graph LR
    A[Stream 1: GET /index.html] --> B[Single TCP Connection]
    C[Stream 2: GET /style.css] --> B
    D[Stream 3: GET /app.js] --> B
    B --> A
    B --> C
    B --> D

This eliminates head-of-line blocking. The browser can request all assets in parallel without waiting.

HTTP/2 also adds header compression (HPACK), server push, and stream prioritization.

HTTP/3: QUIC Transport

HTTP/3 takes a different approach. It runs over QUIC instead of TCP. QUIC is a transport protocol built on UDP.

Why UDP? TCP requires a handshake before sending data. QUIC combines the handshake with TLS, reducing connection establishment time:

graph LR
    A[TCP + TLS 1.2] --> B[3 round trips to ready]
    C[QUIC + TLS 1.3] --> D[1 round trip to ready]

HTTP/3 benefits include faster establishment (0-RTT resumption), no head-of-line blocking, better performance on lossy networks, and connection migration when switching networks.

The catch: HTTP/3 requires UDP traffic to be allowed through firewalls. Most modern sites support it alongside HTTP/2.

HTTPS: HTTP Over TLS

HTTPS adds encryption via TLS (Transport Layer Security). The SSL/TLS and HTTPS post covers the details, but here is the quick version:

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: ClientHello (TLS)
    Server->>Client: ServerHello, Certificate, KeyExchange
    Client->>Server: KeyExchange, ChangeCipherSpec
    Client->>Server: Finished
    Server->>Client: ChangeCipherSpec
    Server->>Client: Finished
    Note over Client,Server: Encrypted HTTP now

The padlock icon in your browser means the connection uses HTTPS and the server certificate has been verified.

Caching with HTTP

HTTP caching reduces server load and improves performance. The Cache-Control header controls caching behavior:

# Cache for 1 hour
Cache-Control: max-age=3600

# Don't cache at all
Cache-Control: no-store

# Check freshness but reuse cached copy
Cache-Control: no-cache

# Cache only on CDN, not in browser
Cache-Control: private, max-age=3600

ETags provide another caching mechanism:

# Server response includes ETag
HTTP/1.1 200 OK
ETag: "v1.2.3"

# Client caches and later checks if changed
GET /api/data HTTP/1.1
If-None-Match: "v1.2.3"

# Server responds with 304 if unchanged
HTTP/1.1 304 Not Modified

When to Use HTTP

HTTP is the right choice when:

You need stateless request-response communication
Clients and servers have no shared state
Standard browser clients need to access your API
You want simple, well-understood semantics
Caching through standard HTTP mechanisms helps performance
You are building web applications, REST APIs, or serving content

When to Use HTTPS

HTTPS is required when:

You transmit any sensitive data (credentials, personal info, payment data)
Your application requires authentication
You need to prevent man-in-the-middle attacks
Browser security warnings would harm your users
You handle session cookies or tokens
Your application deals with financial or healthcare data

When Not to Use HTTP/HTTPS

HTTP/HTTPS may not be the right choice when:

Real-time bidirectional communication is needed (use WebSockets)
You need server-to-server streaming with minimal overhead (use gRPC)
You are building low-latency games or trading systems where TCP/UDP directly makes more sense
You need to push data to clients without polling (consider Server-Sent Events)

Production Failure Scenarios

Failure	Impact	Mitigation
Server returns 500 errors	Users see errors, no data retrieved	Implement retry logic with exponential backoff; monitor error rates
Slow response times	Poor user experience, timeouts	Set appropriate timeouts; use circuit breakers; scale horizontally
SSL/TLS certificate expired	Browser warnings, service unavailable	Automate certificate renewal (Let’s Encrypt, certbot); monitor expiration
Malformed responses	Client crashes or data corruption	Validate responses with schema; implement graceful degradation
Header injection	Security vulnerability	Sanitize all header values; use security headers (HSTS, CSP)
HTTP/2 connection drops	Reconnection overhead	Implement connection pooling; use HTTP/3 as fallback
Reverse proxy timeout	Gateway 504 errors	Configure appropriate timeouts; implement health checks
Content-Type mismatch	Client cannot parse response	Always set correct Content-Type; use content negotiation

Observability Checklist

Metrics

Request rate (requests per second by endpoint, method, status code)
Response latency (p50, p95, p99 by endpoint)
Error rate (4xx, 5xx by type)
Connection pool utilization
Active connections (concurrent requests)
SSL/TLS handshake duration
Certificate expiration tracking

Logs

All requests with method, path, status, duration
Error stack traces with request context (request ID)
Slow requests (> 500ms threshold configurable)
SSL handshake failures and certificate issues
Connection establishment and termination events
Health check results with detailed failures

Alerts

Error rate exceeds 1% for 5 minutes
p99 latency exceeds 2 seconds
SSL certificate expires within 30 days
Active connections approach server limit
Health check failures for more than 30 seconds
Unusual spike in 4xx errors (potential attack)

Security Checklist

Enable HTTPS on all endpoints (no HTTP fallback for sensitive data)
Set Strict-Transport-Security header (HSTS)
Implement Content-Security-Policy header
Set X-Content-Type-Options: nosniff
Set X-Frame-Options: DENY to prevent clickjacking
Remove or obfuscate server version headers
Implement rate limiting to prevent abuse
Use secure, HttpOnly, SameSite cookies
Validate all request headers and body data
Implement CORS properly for cross-origin requests
Log and monitor authentication failures
Use POST, not GET, for sensitive data transmission

Common Pitfalls / Anti-Patterns

Improper Use of Status Codes

Do not return 200 OK for errors. Clients rely on status codes to determine success or failure.

# Wrong - 200 for error
HTTP/1.1 200 OK
{"error": "User not found"}

# Correct - proper status code
HTTP/1.1 404 Not Found
{"error": "User not found"}

Ignoring Idempotency

GET and HEAD should be safe (no side effects). PUT should be idempotent. POST is neither.

# GET with side effects - BAD
GET /api/users/123/activate  # Changes server state!

# Proper REST - use POST or PATCH
POST /api/users/123/activate
PATCH /api/users/123 {"status": "active"}

Not Handling Timeouts

Clients may timeout before server responds. Always implement proper timeout handling and retry logic.

Missing Content-Type

Always specify Content-Type for requests with bodies. Clients may not guess correctly.

# Always specify content type
Content-Type: application/json

Keeping Connections Open Indefinitely

Without Keep-Alive, each request requires a new TCP handshake. With Keep-Alive but no timeout, servers can run out of connections.

Quick Recap

Key Bullets

HTTP is a stateless request-response protocol at the application layer
HTTP methods indicate action: GET (read), POST (create), PUT (replace), PATCH (modify), DELETE (remove)
Status codes group by type: 1xx (info), 2xx (success), 3xx (redirect), 4xx (client error), 5xx (server error)
Headers carry metadata for caching, authentication, content negotiation, and security
HTTP/1.1 introduced persistent connections; HTTP/2 added multiplexing; HTTP/3 uses QUIC over UDP
HTTPS wraps HTTP in TLS encryption, requiring certificates and adding handshake overhead
Always use HTTPS for sensitive data and production services

Copy/Paste Checklist

# Check HTTP headers with curl
curl -I https://example.com

# Check SSL/TLS configuration
curl -v https://example.com 2>&1 | grep -E "(SSL|TLS|HTTP/)"

# Test specific HTTP method
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice"}'

# Check for security headers
curl -I https://example.com | grep -iE "(strict-transport|x-frame|x-content-type)"

# Monitor response time
curl -w "\nTime: %{time_total}s\n" https://example.com

Conclusion

HTTP has evolved significantly from its early days. The core model (request-response) remains, but performance and capabilities have improved across versions. HTTP is a request-response protocol with methods like GET, POST, PUT, DELETE. Status codes group into 1xx (info), 2xx (success), 3xx (redirect), 4xx (client error), 5xx (server error). Headers carry metadata for content negotiation, caching, and authentication. HTTP/1.1 introduced Keep-Alive, HTTP/2 added multiplexing, and HTTP/3 uses QUIC for faster establishment. HTTPS wraps HTTP in TLS encryption.

For security details, see the SSL/TLS and HTTPS post. For transport details, see the TCP/IP & UDP post.

HTTP and HTTPS Protocol: A Complete Guide to Web Communication

What is HTTP?

HTTP Methods

GET

POST

PUT

PATCH

DELETE

Other Methods

HTTP Status Codes

1xx: Informational

2xx: Success

3xx: Redirection

4xx: Client Errors

5xx: Server Errors

HTTP Headers

Common Request Headers

Common Response Headers

Keep-Alive and Connection Management

HTTP/2: Multiplexing

HTTP/3: QUIC Transport

HTTPS: HTTP Over TLS

Caching with HTTP

When to Use HTTP

When to Use HTTPS

When Not to Use HTTP/HTTPS

Production Failure Scenarios

Observability Checklist

Metrics

Logs

Alerts

Security Checklist

Common Pitfalls / Anti-Patterns

Improper Use of Status Codes

Ignoring Idempotency

Not Handling Timeouts

Missing Content-Type

Keeping Connections Open Indefinitely

Quick Recap

Key Bullets

Copy/Paste Checklist

Conclusion

Category

Tags

Related Posts

SSL, TLS, and HTTPS: Securing Web Communication

TCP, IP, and UDP: Understanding Internet Transport Protocols

Cloud Security: IAM, Network Isolation, and Encryption