> For the complete documentation index, see [llms.txt](https://alham-rizvi.gitbook.io/alhamrizvi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alham-rizvi.gitbook.io/alhamrizvi/web-application-pentesting/04.-http-headers-and-request-methods.md). # 04. HTTP Headers & Request Methods #### Every method, every common header, with examples *This file is pure HTTP protocol reference, not attack techniques, useful to have open alongside the others since every attack in those files targets one of the headers or methods listed here.* *** ### Table of Contents 1. HTTP Request Methods 2. Anatomy of an HTTP Request 3. Anatomy of an HTTP Response 4. Request Headers: General 5. Request Headers: Content Negotiation 6. Request Headers: Authentication & Cookies 7. Request Headers: Caching & Conditionals 8. Request Headers: CORS & Security Context 9. Request Headers: Fetch Metadata & Client Hints 10. Response Headers: General & Content 11. Response Headers: Caching 12. Response Headers: Security 13. Response Headers: CORS 14. Response Headers: Cookies & Redirection 15. HTTP Status Codes Quick Reference 16. Full Worked Examples *** ### 1. HTTP Request Methods | Method | Purpose | Has a body? | Idempotent? | Safe (no side effects)? | | --------- | -------------------------------------------------------------------------------- | ------------------ | ------------ | -------------------------------------------------------- | | `GET` | Retrieve a resource | No (by convention) | Yes | Yes | | `POST` | Submit data, create a resource, trigger an action | Yes | No | No | | `PUT` | Replace a resource entirely at a known URL | Yes | Yes | No | | `PATCH` | Partially update a resource | Yes | No (usually) | No | | `DELETE` | Remove a resource | Sometimes | Yes | No | | `HEAD` | Same as GET but returns only headers, no body | No | Yes | Yes | | `OPTIONS` | Ask what methods/headers are allowed on a resource (also used as CORS preflight) | No | Yes | Yes | | `TRACE` | Echoes back the received request, for diagnostics | No | Yes | Yes (but commonly disabled, historically abused for XST) | | `CONNECT` | Establishes a tunnel, used for HTTPS through a proxy | No | No | No | #### Examples **GET** ``` GET /api/users/42 HTTP/1.1 Host: api.example.com ``` **POST** ``` POST /api/users HTTP/1.1 Host: api.example.com Content-Type: application/json Content-Length: 38 {"name":"Alice","email":"a@example.com"} ``` **PUT** ``` PUT /api/users/42 HTTP/1.1 Host: api.example.com Content-Type: application/json Content-Length: 40 {"name":"Alice B","email":"a@example.com"} ``` **PATCH** ``` PATCH /api/users/42 HTTP/1.1 Host: api.example.com Content-Type: application/json Content-Length: 20 {"name":"Alice B"} ``` **DELETE** ``` DELETE /api/users/42 HTTP/1.1 Host: api.example.com Authorization: Bearer eyJhbGciOi... ``` **HEAD** ``` HEAD /api/users/42 HTTP/1.1 Host: api.example.com ``` Response has the same headers a GET would return, but no body, useful for checking existence/size/last-modified without downloading content. **OPTIONS (CORS preflight example)** ``` OPTIONS /api/users HTTP/1.1 Host: api.example.com Origin: https://frontend.example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: content-type, authorization ``` *** ### 2. Anatomy of an HTTP Request ``` METHOD /path?query=string HTTP/1.1 <- request line Header-Name: Header-Value <- one or more headers Header-Name-2: Value2 <- blank line separates headers from body { optional request body } ``` Example, fully annotated: ``` POST /login HTTP/1.1 <- method, path, protocol version Host: example.com <- required in HTTP/1.1, which vhost to route to User-Agent: Mozilla/5.0 ... <- client identification string Accept: application/json <- what response formats the client will accept Content-Type: application/x-www-form-urlencoded <- format of the body being sent Content-Length: 29 <- byte length of the body Cookie: session=abc123 <- cookies previously set by the server username=alice&password=hunter2 <- the body ``` *** ### 3. Anatomy of an HTTP Response ``` HTTP/1.1 200 OK <- status line: protocol, status code, reason phrase Header-Name: Header-Value <- one or more headers <- blank line separates headers from body { response body } ``` Example, fully annotated: ``` HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 <- format/encoding of the body Content-Length: 45 <- byte length of the body Set-Cookie: session=xyz789; HttpOnly; Secure; SameSite=Strict <- sets a cookie Cache-Control: no-store <- caching instructions X-Content-Type-Options: nosniff <- security header {"id":42,"name":"Alice","email":"a@example.com"} ``` *** ### 4. Request Headers: General | Header | Purpose | Example | | ------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------- | | `Host` | Which virtual host/domain the request targets, required in HTTP/1.1 | `Host: example.com` | | `User-Agent` | Identifies the client software/browser/OS | `User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)` | | `Referer` | The URL of the page that linked to this request (note the classic protocol misspelling) | `Referer: https://example.com/search` | | `Connection` | Controls whether the network connection stays open after this exchange | `Connection: keep-alive` | | `Upgrade` | Requests a protocol switch (e.g. to WebSocket) | `Upgrade: websocket` | | `Content-Type` | Format of the request body | `Content-Type: application/json` | | `Content-Length` | Byte length of the request body | `Content-Length: 348` | | `Transfer-Encoding` | Alternative to Content-Length, body sent in chunks | `Transfer-Encoding: chunked` | | `X-Requested-With` | Legacy marker often used to identify AJAX requests | `X-Requested-With: XMLHttpRequest` | *** ### 5. Request Headers: Content Negotiation | Header | Purpose | Example | | ----------------- | --------------------------------------------------- | ------------------------------------------ | | `Accept` | What response content types the client can handle | `Accept: text/html,application/json` | | `Accept-Language` | Preferred response language(s) | `Accept-Language: en-US,en;q=0.9,fr;q=0.8` | | `Accept-Encoding` | Compression formats the client can decode | `Accept-Encoding: gzip, deflate, br` | | `Accept-Charset` | Preferred character encoding (largely legacy today) | `Accept-Charset: utf-8` | *** ### 6. Request Headers: Authentication & Cookies | Header | Purpose | Example | | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | `Authorization` | Credentials for the request (Basic, Bearer, Digest, etc.) | `Authorization: Bearer eyJhbGciOiJIUzI1NiIs...` | | `Cookie` | Sends previously stored cookies back to the server | `Cookie: session=abc123; theme=dark` | | `Proxy-Authorization` | Credentials for an intermediate proxy, not the final server | `Proxy-Authorization: Basic dXNlcjpwYXNz` | | `WWW-Authenticate` (response, listed here for context) | Server tells client which auth scheme is required, prompting a retried request with `Authorization` | `WWW-Authenticate: Basic realm="Admin Area"` | Common `Authorization` schemes: ``` Authorization: Basic dXNlcjpwYXNzd29yZA== <- base64(username:password) Authorization: Bearer eyJhbGciOi... <- OAuth2/JWT token Authorization: Digest username="user", realm="..." <- digest auth, rarely seen now ``` *** ### 7. Request Headers: Caching & Conditionals | Header | Purpose | Example | | --------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------- | | `Cache-Control` | Client's caching directives for this request | `Cache-Control: no-cache` | | `If-Modified-Since` | Only return the resource if changed since this date (conditional GET) | `If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT` | | `If-None-Match` | Only return the resource if its ETag differs from the given value | `If-None-Match: "33a64df5"` | | `If-Match` | Only proceed if the resource's current ETag matches (used for safe updates) | `If-Match: "33a64df5"` | | `If-Unmodified-Since` | Only proceed if unchanged since the given date | `If-Unmodified-Since: Wed, 21 Oct 2025 07:28:00 GMT` | | `Range` | Request only part of a resource (partial content, e.g. resuming a download) | `Range: bytes=0-1023` | *** ### 8. Request Headers: **Cross-Origin Resource Sharing (**CORS) & Security Context | Header | Purpose | Example | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------- | | `Origin` | The origin (scheme+host+port) the request is coming from, sent automatically by browsers for cross-origin requests | `Origin: https://frontend.example.com` | | `Access-Control-Request-Method` | Sent in a CORS preflight, the method the actual request will use | `Access-Control-Request-Method: PUT` | | `Access-Control-Request-Headers` | Sent in a CORS preflight, the custom headers the actual request will include | `Access-Control-Request-Headers: content-type, x-api-key` | | `X-Forwarded-For` | Chain of client IPs when passing through proxies (client-controllable, not inherently trustworthy) | `X-Forwarded-For: 203.0.113.5, 70.41.3.18` | | `X-Forwarded-Host` | Original Host header when passing through a proxy | `X-Forwarded-Host: example.com` | | `X-Forwarded-Proto` | Original scheme (http/https) when passing through a proxy | `X-Forwarded-Proto: https` | | `DNT` | "Do Not Track" preference signal, largely deprecated/ignored today | `DNT: 1` | *** ### 9. Request Headers: Fetch Metadata & Client Hints Modern browsers send additional context automatically, useful for both defenders (server-side request validation) and testers (fingerprinting how a request was actually triggered): | Header | Purpose | Example | | -------------------- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | `Sec-Fetch-Site` | Relationship between the request's initiator and target origin | `Sec-Fetch-Site: same-origin` (also: `same-site`, `cross-site`, `none`) | | `Sec-Fetch-Mode` | The request mode (navigate, cors, no-cors, etc.) | `Sec-Fetch-Mode: navigate` | | `Sec-Fetch-Dest` | What the request will be used for (document, image, script, etc.) | `Sec-Fetch-Dest: document` | | `Sec-Fetch-User` | Whether the request was triggered by a genuine user activation (like a click) | `Sec-Fetch-User: ?1` | | `Sec-CH-UA` | Client hint: browser brand/version | `Sec-CH-UA: "Chromium";v="124"` | | `Sec-CH-UA-Platform` | Client hint: operating system | `Sec-CH-UA-Platform: "Windows"` | These `Sec-Fetch-*` headers are particularly useful defensively: a server can reject a sensitive state-changing request where `Sec-Fetch-Site: cross-site`, as a lightweight extra layer alongside CSRF tokens. *** ### 10. Response Headers: General & Content | Header | Purpose | Example | | --------------------- | --------------------------------------------------------------------------------------- | -------------------------------------------------------- | | `Content-Type` | Format/encoding of the response body | `Content-Type: text/html; charset=utf-8` | | `Content-Length` | Byte length of the response body | `Content-Length: 1024` | | `Content-Encoding` | Compression applied to the body | `Content-Encoding: gzip` | | `Content-Disposition` | Whether content should display inline or download as a file, and its suggested filename | `Content-Disposition: attachment; filename="report.pdf"` | | `Content-Language` | Language of the response content | `Content-Language: en-US` | | `Server` | Identifies the server software (often trimmed/hidden for security reasons) | `Server: nginx/1.25.3` | | `Date` | When the response was generated | `Date: Wed, 22 Jul 2026 10:00:00 GMT` | | `Location` | Target URL for a redirect response, or the URL of a newly created resource | `Location: https://example.com/new-page` | | `Vary` | Which request headers affect caching/content selection for this response | `Vary: Accept-Encoding, Origin` | | `Retry-After` | How long to wait before retrying, used with 429/503 responses | `Retry-After: 120` | *** ### 11. Response Headers: Caching | Header | Purpose | Example | | --------------- | -------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | | `Cache-Control` | Caching directives for clients and intermediate caches | `Cache-Control: public, max-age=3600` | | `Expires` | Absolute expiration date for the cached response (legacy, `Cache-Control: max-age` takes precedence when both are present) | `Expires: Wed, 22 Jul 2026 11:00:00 GMT` | | `ETag` | Opaque identifier for a specific version of a resource, used for conditional requests | `ETag: "33a64df5"` | | `Last-Modified` | When the resource was last changed | `Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT` | | `Age` | How long (in seconds) a cached response has been held by an intermediate cache | `Age: 120` | Common `Cache-Control` directives: ``` Cache-Control: no-store <- never cache this response at all Cache-Control: no-cache <- may cache, but must revalidate before reuse Cache-Control: private <- only cache in the end user's own browser, not shared caches/CDNs Cache-Control: public, max-age=86400 <- cacheable by anyone for 24 hours Cache-Control: immutable <- content will never change, skip revalidation entirely ``` *** ### 12. Response Headers: Security | Header | Purpose | Example | | ------------------------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | `Content-Security-Policy` | Restricts what sources scripts/styles/images/etc. can load from, primary XSS mitigation | `Content-Security-Policy: default-src 'self'; script-src 'nonce-abc123'` | | `X-Content-Type-Options` | Prevents MIME-sniffing, forces the browser to respect the declared Content-Type | `X-Content-Type-Options: nosniff` | | `X-Frame-Options` | Legacy clickjacking protection, controls whether the page can be framed | `X-Frame-Options: DENY` | | `Strict-Transport-Security` | Forces HTTPS for all future requests to this domain (HSTS) | `Strict-Transport-Security: max-age=31536000; includeSubDomains` | | `Referrer-Policy` | Controls how much of the URL is sent in the Referer header on outbound navigation | `Referrer-Policy: strict-origin-when-cross-origin` | | `Permissions-Policy` | Controls which browser features/APIs (camera, geolocation, etc.) the page can use | `Permissions-Policy: geolocation=(), camera=()` | | `X-XSS-Protection` | Legacy browser XSS filter toggle, deprecated in modern browsers, CSP is the real replacement | `X-XSS-Protection: 0` | | `Cross-Origin-Opener-Policy` | Isolates the page's browsing context from cross-origin windows | `Cross-Origin-Opener-Policy: same-origin` | | `Cross-Origin-Embedder-Policy` | Requires explicit opt-in for cross-origin resources to be embedded | `Cross-Origin-Embedder-Policy: require-corp` | | `Cross-Origin-Resource-Policy` | Controls which origins can load this resource at all | `Cross-Origin-Resource-Policy: same-origin` | *** ### 13. Response Headers: CORS | Header | Purpose | Example | | ---------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | `Access-Control-Allow-Origin` | Which origin(s) may read this cross-origin response | `Access-Control-Allow-Origin: https://frontend.example.com` | | `Access-Control-Allow-Methods` | Which HTTP methods are allowed cross-origin | `Access-Control-Allow-Methods: GET, POST, PUT, DELETE` | | `Access-Control-Allow-Headers` | Which request headers are allowed cross-origin | `Access-Control-Allow-Headers: Content-Type, Authorization` | | `Access-Control-Allow-Credentials` | Whether cookies/credentials may be included in the cross-origin request | `Access-Control-Allow-Credentials: true` | | `Access-Control-Expose-Headers` | Which response headers JS is allowed to read cross-origin (browsers hide most by default) | `Access-Control-Expose-Headers: X-Total-Count` | | `Access-Control-Max-Age` | How long the browser may cache a preflight response | `Access-Control-Max-Age: 600` | Important rule: `Access-Control-Allow-Origin: *` and `Access-Control-Allow-Credentials: true` can never be combined per spec, browsers reject that combination, since it would allow any site to read authenticated responses. *** ### 14. Response Headers: Cookies & Redirection | Header | Purpose | Example | | ----------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | `Set-Cookie` | Sets a cookie in the client | `Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=3600` | | `Location` | Redirect target (used with 3xx status codes) | `Location: /dashboard` | | `Clear-Site-Data` | Instructs the browser to clear cookies/storage/cache for this origin, useful on logout | `Clear-Site-Data: "cookies", "storage"` | `Set-Cookie` attribute breakdown: ``` Set-Cookie: name=value; Expires=Wed, 22 Jul 2026 12:00:00 GMT; <- absolute expiration Max-Age=3600; <- relative expiration in seconds, takes precedence over Expires Domain=example.com; <- which domain(s) the cookie applies to Path=/; <- which paths the cookie applies to Secure; <- only sent over HTTPS HttpOnly; <- not accessible to JavaScript (document.cookie) SameSite=Strict; <- Strict, Lax, or None, controls cross-site sending ``` *** ### 15. HTTP Status Codes Quick Reference | Range | Category | Common examples | | ----- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | 1xx | Informational | `100 Continue`, `101 Switching Protocols` | | 2xx | Success | `200 OK`, `201 Created`, `202 Accepted`, `204 No Content` | | 3xx | Redirection | `301 Moved Permanently`, `302 Found`, `304 Not Modified`, `307 Temporary Redirect`, `308 Permanent Redirect` | | 4xx | Client error | `400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found`, `405 Method Not Allowed`, `409 Conflict`, `429 Too Many Requests` | | 5xx | Server error | `500 Internal Server Error`, `502 Bad Gateway`, `503 Service Unavailable`, `504 Gateway Timeout` | Notes worth remembering: * `401` means "you're not authenticated," `403` means "you are authenticated, but not allowed." Mixing these up is a common access-control finding in itself (leaking whether a resource exists at all to unauthenticated users). * `301`/`308` are permanent and cacheable by browsers long-term, `302`/`307` are temporary. `301`/`302` historically allowed a method change on redirect (e.g. POST becoming GET); `307`/`308` explicitly preserve the original method. * `429` should be paired with a `Retry-After` header telling the client how long to back off. *** ### 16. Full Worked Examples #### A complete login request/response pair **Request** ``` POST /api/login HTTP/1.1 Host: app.example.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Accept: application/json Content-Type: application/json Content-Length: 46 Origin: https://app.example.com Sec-Fetch-Site: same-origin {"username":"alice","password":"hunter2"} ``` **Response** ``` HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Content-Length: 58 Set-Cookie: session=9f8e7d6c5b; HttpOnly; Secure; SameSite=Strict; Path=/ Cache-Control: no-store X-Content-Type-Options: nosniff Content-Security-Policy: default-src 'self' {"success":true,"user":{"id":42,"username":"alice"}} ``` #### A file download response ``` HTTP/1.1 200 OK Content-Type: application/pdf Content-Length: 204800 Content-Disposition: attachment; filename="invoice-2026.pdf" X-Content-Type-Options: nosniff Cache-Control: private, no-store ``` #### A CORS preflight and its response **Request (preflight)** ``` OPTIONS /api/data HTTP/1.1 Host: api.example.com Origin: https://app.example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: content-type, authorization ``` **Response (preflight)** ``` HTTP/1.1 204 No Content Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: Content-Type, Authorization Access-Control-Allow-Credentials: true Access-Control-Max-Age: 600 ``` #### A redirect ``` HTTP/1.1 302 Found Location: https://app.example.com/dashboard Cache-Control: no-cache ``` #### A rate-limited response ``` HTTP/1.1 429 Too Many Requests Retry-After: 60 Content-Type: application/json {"error":"rate_limit_exceeded","retry_after_seconds":60} ``` *** ### See Also This reference underpins every technique in the companion cheatsheets: * `XSS_Cheatsheet.md`, `content-security-policy` and `x-content-type-options` from Section 12 are the primary XSS mitigations discussed there * `Open_Redirect_Cheatsheet.md`, the `Location` header from Section 14 is the core mechanism being abused * `CRLF_Injection_Cheatsheet.md`, this entire reference is what CRLF injection lets an attacker forge or corrupt * `HTTP_Header_Injection_Cheatsheet.md`, Sections 4, 6, and 8 here (Host, X-Forwarded-\*, and the general header/method anatomy) are exactly the headers that cheatsheet shows being abused --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://alham-rizvi.gitbook.io/alhamrizvi/web-application-pentesting/04.-http-headers-and-request-methods.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.