HTTP Protocols: Difference between revisions
Line 137: | Line 137: | ||
|} | |} | ||
== | == Common HTTP Headers == | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 144: | Line 144: | ||
| Host || Indicates the domain being requested | | Host || Indicates the domain being requested | ||
|- | |- | ||
| User-Agent || Identifies the requesting client | | User-Agent || Identifies the requesting client software | ||
|- | |- | ||
| Accept || Lists acceptable response | | Accept || Lists acceptable response media types | ||
|- | |||
| Accept-Encoding || Lists acceptable compression algorithms (e.g., gzip, br) | |||
|- | |||
| Accept-Language || Lists acceptable languages for the response | |||
|- | |- | ||
| Authorization || Contains credentials (e.g., Basic or Bearer) | | Authorization || Contains credentials (e.g., Basic or Bearer) | ||
|- | |- | ||
| Content-Type || Declares media type of the request | | Content-Type || Declares the media type of the request or response body | ||
|- | |||
| Content-Length || Size of the body in bytes | |||
|- | |||
| Cache-Control || Directives for caching mechanisms | |||
|- | |||
| Connection || Controls whether the connection should be kept alive | |||
|- | |||
| Cookie || Sends stored cookies from the client to the server | |||
|- | |||
| Set-Cookie || Instructs client to store a cookie | |||
|- | |||
| Referer || Indicates the address of the previous web page | |||
|- | |||
| Origin || Indicates where the request originated from (used in CORS) | |||
|- | |||
| Location || Indicates the URL to redirect a client to (used with 3xx responses) | |||
|- | |||
| X-Forwarded-For || Shows original IP when behind a proxy/load balancer | |||
|- | |||
| Upgrade-Insecure-Requests || Indicates client prefers secure content (HTTPS) | |||
|- | |- | ||
| | | If-Modified-Since || Used to make conditional requests based on last modification date | ||
|- | |- | ||
| | | ETag || Identifier for specific version of a resource | ||
|- | |- | ||
| | | Range || Requests partial content (used in downloads/streaming) | ||
|} | |} | ||
Latest revision as of 09:37, 14 June 2025
HTTP Protocols[edit | edit source]
Introduction[edit | edit source]
The Hypertext Transfer Protocol (HTTP) is the application-layer protocol used for communication between clients and servers on the web. It enables retrieval of resources such as HTML, JSON, or binary content by defining a standardized format for request and response messages.
HTTP is stateless, meaning each request is independent unless explicitly managed using sessions, cookies, or tokens.
HTTP vs HTTPS[edit | edit source]
Feature | HTTP | HTTPS |
---|---|---|
Encryption | No | Yes (via TLS) |
Default Port | 80 | 443 |
Visibility | Unencrypted, readable by intermediaries | Encrypted end-to-end |
Certificate Required | No | Yes (X.509 certificate) |
HTTPS is HTTP over TLS (Transport Layer Security). It provides integrity, confidentiality, and authentication using cryptographic certificates and a handshake process.
Request Structure[edit | edit source]
An HTTP request typically consists of:
- A request line
e.g., `GET /index.html HTTP/1.1`
- Request headers
e.g., `Host`, `User-Agent`, `Accept`, `Content-Type`
- Optional body (for methods like POST or PUT)
Example:
GET /resource HTTP/1.1 Host: example.com User-Agent: curl/8.0 Accept: */*
Response Structure[edit | edit source]
An HTTP response from a server includes:
- A status line
e.g., `HTTP/1.1 200 OK`
- Response headers
e.g., `Content-Type`, `Server`, `Set-Cookie`
- Optional body (e.g., JSON, HTML, binary data)
Example:
HTTP/1.1 200 OK Content-Type: application/json Content-Length: 48 {"status":"ok","data":["value1","value2"]}
HTTP Methods[edit | edit source]
Method | Description | Notes |
---|---|---|
GET | Retrieves a resource | No side effects expected |
POST | Submits data to a resource | Used for creating or triggering actions |
PUT | Replaces a resource | Idempotent |
PATCH | Partially modifies a resource | Efficient for small updates |
DELETE | Removes a resource | Use with caution |
HEAD | Same as GET but returns headers only | Used for validation |
OPTIONS | Returns allowed methods for a resource | Used in CORS preflight |
Status Codes[edit | edit source]
HTTP status codes are three-digit numbers returned by the server to indicate the result of a request. They are grouped into five categories based on their first digit.
Code Range | Category | Description |
---|---|---|
100–199 | Informational Responses | Initial part of the request received; client should continue. Rarely used today. |
200–299 | Successful Responses | Request was successfully received, understood, and accepted. |
300–399 | Redirection Messages | Further action is needed by the client, often a new URI. |
400–499 | Client Error Responses | The request is malformed or cannot be processed due to client-side issues. |
500–599 | Server Error Responses | Server failed to fulfill a valid request due to internal error or overload. |
Code | Category | Meaning | Example Scenario |
---|---|---|---|
100 | Informational | Continue | Client should continue the request |
101 | Informational | Switching Protocols | Protocol upgrade requested |
200 | Success | OK | Standard response for successful request |
201 | Success | Created | Resource successfully created (e.g., via POST) |
204 | Success | No Content | Request succeeded, no body returned |
301 | Redirection | Moved Permanently | Resource has a new permanent URI |
302 | Redirection | Found | Temporarily redirected to another URI |
304 | Redirection | Not Modified | Cached content is still valid |
400 | Client Error | Bad Request | Malformed syntax or invalid parameters |
401 | Client Error | Unauthorized | Authentication required |
403 | Client Error | Forbidden | Request denied despite authentication |
404 | Client Error | Not Found | Resource not found at requested URI |
405 | Client Error | Method Not Allowed | Method not supported on resource |
408 | Client Error | Request Timeout | Server timed out waiting for request |
429 | Client Error | Too Many Requests | Rate-limiting or abuse prevention |
500 | Server Error | Internal Server Error | Generic server failure |
502 | Server Error | Bad Gateway | Invalid response from upstream server |
503 | Server Error | Service Unavailable | Server temporarily overloaded or down |
504 | Server Error | Gateway Timeout | Upstream server did not respond in time |
Common HTTP Headers[edit | edit source]
Header | Purpose |
---|---|
Host | Indicates the domain being requested |
User-Agent | Identifies the requesting client software |
Accept | Lists acceptable response media types |
Accept-Encoding | Lists acceptable compression algorithms (e.g., gzip, br) |
Accept-Language | Lists acceptable languages for the response |
Authorization | Contains credentials (e.g., Basic or Bearer) |
Content-Type | Declares the media type of the request or response body |
Content-Length | Size of the body in bytes |
Cache-Control | Directives for caching mechanisms |
Connection | Controls whether the connection should be kept alive |
Cookie | Sends stored cookies from the client to the server |
Set-Cookie | Instructs client to store a cookie |
Referer | Indicates the address of the previous web page |
Origin | Indicates where the request originated from (used in CORS) |
Location | Indicates the URL to redirect a client to (used with 3xx responses) |
X-Forwarded-For | Shows original IP when behind a proxy/load balancer |
Upgrade-Insecure-Requests | Indicates client prefers secure content (HTTPS) |
If-Modified-Since | Used to make conditional requests based on last modification date |
ETag | Identifier for specific version of a resource |
Range | Requests partial content (used in downloads/streaming) |
Session Handling[edit | edit source]
Because HTTP is stateless, persistent user sessions require one or more of the following:
- Cookies – Stored on the client to identify a session
- Session IDs – Server-stored session reference
- JWT (JSON Web Tokens) – Signed token containing session data
These mechanisms allow users to remain "logged in" and retain application context across requests.
Caching and Proxying[edit | edit source]
Caching is used to reduce latency and bandwidth usage. Proxy servers and browsers often store cacheable responses using headers like:
- `Cache-Control`
- `ETag`
- `Last-Modified`
- `Expires`
Caching behavior is controlled using these headers to define rules like expiration time, revalidation conditions, or cache-bypass.
TLS Handshake (in HTTPS)[edit | edit source]
The TLS handshake occurs before any HTTP data is exchanged:
- ClientHello: Client proposes supported ciphers and sends a random value
- ServerHello: Server selects a cipher and provides its certificate
- Key exchange: Secure key is derived
- Symmetric encryption begins
This secures the session and validates the server identity.
Diagnostic Tools[edit | edit source]
Tool | Example Usage | Function |
---|---|---|
curl | curl -v https://example.com | Command-line HTTP client |
wget | wget https://example.com/file.txt | File downloader |
tcpdump | tcpdump -A -i eth0 port 80 | Inspect raw HTTP packets |
mitmproxy | mitmproxy -p 8080 | Intercept and modify traffic |
browser devtools | F12 → Network tab | View request and response headers |
Common Weaknesses[edit | edit source]
- Sensitive data in query parameters (GET)
- Lack of TLS encryption on login forms
- Broad `Access-Control-Allow-Origin` headers
- Improper use of caching for private data
- Default error pages revealing server information
See also[edit | edit source]
- curl
- /tcpdump