HTTP request and response headers glossary

HTTP request headers

Request headers are sent from the client (browser, bot, API consumer) to the server as part of an HTTP request. They provide context about the client, the requested resource and how the response should be handled.

Accept header

The Accept header specifies which media types a client can process in response to a request. It lists preferred content types such as text/html, application/json, application/xml or image formats.

Servers use the Accept header for content negotiation, selecting the most appropriate representation of a resource based on the client’s stated preferences. If multiple formats are available, the server may return the best match or respond with 406 Not Acceptable if none are supported.

Proper Accept configuration ensures compatibility between clients and servers and allows APIs and web applications to deliver content in the expected format.

Accept-Encoding header

The Accept-Encoding header specifies which compression methods a client supports, such as gzip or br. Servers use this information to determine whether a compressed response can be returned.

Compression reduces payload size, lowers bandwidth usage and improves transfer speed. If the server applies an unsupported or misconfigured encoding, clients may fail to decode the response or receive unnecessarily large payloads.

Accept-Language header

The Accept-Language header specifies the client’s preferred languages for a response.

Servers use this header during language negotiation to select an appropriate localized representation when multiple versions are available. Improper handling can affect caching behavior and may lead to inconsistent content delivery or duplicate indexing across language variants.

Authorization header

The Authorization header carries authentication credentials within an HTTP request. It includes tokens, API keys or basic authentication data used to access protected resources.

Servers validate the Authorization header to enforce identity verification and access control. Improper handling can expose sensitive endpoints, weaken security boundaries or block legitimate requests.

Cookie header

The Cookie header sends stored cookies from the client to the server with each request.

Cookies maintain session state, user preferences and tracking identifiers. Excessive cookie size or improper configuration can increase request payloads and reduce caching efficiency.

Host header

The Host header specifies the domain name being requested.

It enables virtual hosting by allowing multiple domains to share a single IP address. Accurate Host handling is critical for routing accuracy, SSL certificate validation and correct redirect behavior.

If-Match header

The If-Match header indicates that the request is processed only if the current resource matches a specified ETag value. The client includes a previously received ETag to verify that the resource has not changed before performing an update.

This header enforces optimistic concurrency control by preventing modifications when the underlying resource has been altered. If the ETag does not match, the server typically responds with 412 Precondition Failed, avoiding unintended overwrites and preserving data integrity.

If-Modified-Since header

The If-Modified-Since header requests a resource only if it has changed since a specified timestamp. The header allows the server to compare the provided date with the resource’s last modification time.

If the content has not changed, the server responds with 304 Not Modified instead of retransmitting the full response. This conditional validation reduces bandwidth usage, lowers server load and improves caching efficiency across browsers and CDNs.

If-None-Match header

The If-None-Match header uses ETag-based validation to determine whether a resource has changed. The client sends a previously received ETag to check for content updates.

ETag comparison enables 304 Not Modified responses, reducing redundant downloads. Improper ETag handling across distributed systems can lead to inconsistent caching behavior.

If-Unmodified-Since header

The If-Unmodified-Since header allows a request to proceed only if the resource has not been modified since a specified timestamp. The client provides a date and the server compares it to the resource’s last modification time before applying the request.

If the resource has changed after the given date, the server typically responds with 412 Precondition Failed, preventing the update. The If-Unmodified-Since header adds a safeguard against race conditions and protects data integrity in concurrent or distributed environments.

Origin header

The Origin header identifies the scheme, domain and port that initiated a request. Browsers automatically include this header in cross-origin requests to indicate where the request originated.

Servers evaluate the Origin value against their CORS policy to determine whether the request should be allowed. Proper validation prevents unauthorized cross-domain access while still supporting legitimate API integrations and third-party services.

Range header

The Range header requests a specific byte range of a resource rather than the entire response body. The header allows partial retrieval of large files, commonly used for media streaming, segmented downloads and resuming interrupted transfers.

When a valid range is supplied, the server responds with 206 Partial Content and includes only the requested portion of the resource. Range requests reduce bandwidth usage, improve transfer efficiency and enable reliable resumable downloads.

Referer header

The Referer header indicates the URL of the page that initiated a request. Browsers include this header when navigating between pages or loading embedded resources.

Servers use the Referer value for analytics, request validation and security checks. Because it can include full URLs with query parameters, improper configuration may expose sensitive information. Referrer handling should be paired with an appropriate Referrer-Policy to control data sharing.

Upgrade-Insecure-Requests header

The Upgrade-Insecure-Requests header signals a browser’s preference for secure HTTPS versions of resources when available.

The header supports HTTPS migrations by encouraging automatic upgrades from HTTP to HTTPS. Proper handling reduces mixed content risks and strengthens overall transport security during transitional deployments.

User-Agent header

The User-Agent header identifies the client software making a request. It typically includes information about the browser, rendering engine, version and operating system.

Servers use the User-Agent value for compatibility handling, analytics segmentation and crawler detection. Because client signatures frequently change, heavy reliance on User-Agent parsing can introduce maintenance complexity and brittle logic.

Feature detection and capability-based checks are often more reliable than strict signature matching.

HTTP response headers

Response headers are sent from the server back to the client as part of an HTTP response. They provide metadata about the resource, caching behavior, security policies and redirect instructions.

Accept-Ranges header

The Accept-Ranges header indicates whether a server supports partial content requests. When set to bytes, it confirms that the resource can be requested in segments.

Resumable downloads and streaming rely on proper range support. If Accept-Ranges is not present or disabled, clients must request the entire resource instead of specific portions.

Access-Control-Allow-Origin header

The Access-Control-Allow-Origin header specifies which origins are permitted to access a resource. The header defines whether a specific domain or all origins (*) are allowed to make cross-origin requests.

Browsers compare the Origin header in the request with the value returned in Access-Control-Allow-Origin before exposing the response to client-side code. Incorrect configuration can block legitimate integrations or unintentionally expose protected resources.

Allow header

The Allow header communicates which HTTP methods are permitted for a resource, such as GET, POST, PUT or DELETE.

This header is typically returned with a 405 Method Not Allowed response to indicate valid request methods. Clear method declarations support predictable API behavior and proper request validation.

Cache-Control header

The Cache-Control header defines caching behavior using directives such as max-age, no-store, no-cache, public and private.

It determines how browsers, CDNs and proxies store and reuse responses. Proper configuration improves performance and reduces server load, while incorrect directives can result in stale content or unnecessary revalidation.

Content-Disposition header

The Content-Disposition header instructs the browser on how to handle returned content. The header determines whether content is displayed inline or downloaded as an attachment, often with a specified filename.

Accurate configuration ensures predictable file handling and a consistent user experience. Misconfigured values can trigger unintended downloads or prevent content from rendering properly.

Content-Encoding header

The Content-Encoding header indicates that the response body has been compressed using methods such as gzip or br.

The header tells the client how to decode the response before processing it. Proper compression reduces payload size and improves transfer speed, while mismatched encoding settings can result in corrupted or unreadable responses.

Content-Length header

The Content-Length header specifies the size of the response body in bytes.

Clients use this value to determine when the full response has been received. Incorrect Content-Length values can cause incomplete transfers, stalled connections or response truncation.

Content-Range header

The Content-Range header specifies which portion of a resource is being returned in response to a Range request. It defines the byte range delivered and the total size of the resource.

This header accompanies 206 Partial Content responses and ensures the client understands how the partial segment fits into the complete file. Accurate range handling is essential for streaming, resumable downloads and segmented transfers.

Content-Security-Policy (CSP) header

The Content-Security-Policy (CSP) header defines which sources of content are allowed to load on a page. CSP restricts scripts, styles, images and other resources to reduce the risk of cross-site scripting (XSS) and injection attacks.

Browsers enforce the policy defined in the Content-Security-Policy header before executing or rendering external resources. Overly permissive policies weaken protection, while overly restrictive rules can disrupt legitimate functionality.

Content-Type header

The Content-Type header declares the media type of the response body, such as text/html, application/json or image/png.

Browsers rely on the Content-Type header to interpret and render content correctly. Incorrect or ambiguous values can cause rendering errors, security issues or unintended file handling behavior.

Cross-Origin-Embedder-Policy (COEP) header

The Cross-Origin-Embedder-Policy (COEP) header restricts the loading of cross-origin resources unless explicitly granted permission.

This header requires embedded resources to opt in to cross-origin access. When combined with COOP and CORP, it enables cross-origin isolation, which is necessary for certain advanced browser features and stronger security boundaries.

Cross-Origin-Opener-Policy (COOP) header

The Cross-Origin-Opener-Policy (COOP) header isolates a document’s browsing context from other origins.

This header prevents cross-origin documents from sharing the same browsing context group. Proper configuration reduces exposure to cross-origin attacks and supports secure cross-origin isolation.

Cross-Origin-Resource-Policy (CORP) header

The Cross-Origin-Resource-Policy (CORP) header restricts which origins may load a given resource.

This header blocks unauthorized cross-origin embedding unless the requesting origin is permitted. CORP strengthens resource isolation and works alongside CORS, COEP and COOP to enforce cross-origin security boundaries.

ETag header

The ETag header uniquely identifies a specific version of a resource. The server generates an ETag value and includes it in the response to represent the current state of the content.

Clients store the ETag and send it back in subsequent requests using headers such as If-None-Match or If-Match to determine whether the resource has changed. If the ETag matches, the server can return 304 Not Modified, avoiding retransmission of unchanged content.

Proper ETag implementation improves caching efficiency and reduces bandwidth usage. In distributed or multi-server environments, inconsistent ETag generation can reduce cache effectiveness or cause unexpected validation behavior.

Expires header

The Expires header sets a fixed date and time when cached content becomes stale. Once expired, a fresh request must be made.

Expires differs from Cache-Control and is less flexible due to its absolute timestamp. Modern configurations typically prefer Cache-Control for more precise behavior.

Last-Modified header

The Last-Modified header indicates when a resource was last updated. Browsers use this value for conditional requests.

Last-Modified improves caching efficiency and reduces bandwidth usage when content remains unchanged.

Location header

The Location header communicates redirect destinations in HTTP responses. It is only included in 3xx status codes for redirection and instructs clients where to navigate next.

Proper Location handling ensures clean redirect flows and prevents loops or misrouting. Incorrect values can cause broken navigation or unintended redirect chains.

Permissions-Policy header

The Permissions-Policy header restricts access to browser features such as camera, geolocation or fullscreen mode.

It defines which features are enabled or disabled for a given origin or embedded context. Proper configuration limits unnecessary exposure while maintaining required functionality.

Pragma header

The Pragma header provides legacy cache control instructions, most commonly Pragma: no-cache. It was originally introduced in HTTP/1.0 to prevent cached responses from being reused.

Pragma is largely superseded by Cache-Control in modern HTTP implementations. While some browsers and proxies still recognize Pragma: no-cache for backward compatibility, the current best practice is to rely on Cache-Control directives for more precise and reliable caching behavior.

Referrer-Policy header

The Referrer-Policy header controls how much referrer information is shared when users navigate between pages or when a page loads external resources.

It defines whether the browser sends the full URL, only the origin (scheme and domain) or no referrer data at all with outgoing requests. Proper configuration protects sensitive URL data while preserving the level of analytics and referral insight required.

Retry-After header

The Retry-After header instructs a client to wait before attempting another request. It is commonly returned with 429 Too Many Requests or 503 Service Unavailable responses.

The Retry-After header may specify a delay in seconds or a specific date and time. Proper use supports rate limiting, protects backend systems and encourages well-behaved client retry logic.

Server header

The Server header identifies the web server software handling the request.

Although useful for diagnostics, exposing detailed server information can increase security risk by revealing implementation details.

Set-Cookie header

The Set-Cookie header instructs the browser to store a cookie for use in subsequent requests.

It defines attributes such as Secure, HttpOnly, SameSite, expiration timing and domain scope. Proper configuration protects session integrity and reduces exposure to cross-site and client-side attacks.

Strict-Transport-Security (HSTS) header

The Strict-Transport-Security (HSTS) header forces browsers to use HTTPS for future requests to a site. Once set, the browser automatically upgrades HTTP requests to HTTPS for the duration defined by the max-age directive.

HSTS prevents insecure connections and downgrade attacks. Proper configuration strengthens transport security, while an incorrect setup can cause access issues if HTTPS is not fully supported.

Transfer-Encoding header

The Transfer-Encoding header indicates the method used to transmit the response body when its total size is not known in advance.

When set to chunked, the response is sent in segments without requiring a predefined Content-Length. Proper Transfer-Encoding handling ensures reliable streaming and efficient connection management.

Vary header

The Vary header signals which request headers influence the cached representation of a resource.

Caches store separate response variants based on the headers listed in Vary, such as Accept-Encoding or Accept-Language. Incorrect configuration can fragment cache storage or deliver mismatched content.

WWW-Authenticate header

The WWW-Authenticate header challenges a client to provide authentication credentials.

It accompanies 401 Unauthorized responses and specifies the required authentication scheme. Proper configuration enables secure login flows and controlled access to protected resources.

X-Content-Type-Options header

The X-Content-Type-Options header instructs browsers not to MIME-sniff or guess content types.

When set to nosniff, the header forces browsers to respect the declared Content-Type. Proper enforcement reduces exposure to certain script execution and file interpretation vulnerabilities.

X-Frame-Options header

The X-Frame-Options header controls whether pages can be embedded in frames or iframes.

Framing restrictions prevent clickjacking while potentially affecting legitimate embeds or integrations.

X-Powered-By header

The X-Powered-By header indicates which software, service or platform handled a request. This information is often included automatically by servers or intermediaries.

Although it can assist with debugging, the header provides no functional benefit to end users, browsers or search engines. At the same time, it exposes backend implementation details that may increase security risk. For that reason, it is commonly removed in production environments.

X-Robots-Tag header

The X-Robots-Tag header provides directives to search engines at the HTTP header level.

This header supports directives such as noindex, nofollow and noarchive for non-HTML resources or entire responses. It provides the same control as a meta robots tag while extending indexing management beyond standard web pages.

By Shannon Young

Customer Success Manager

Shannon is a seasoned professional in the customer success space. She has years of experience in a wide variety of customer-facing roles in various sectors.

Always ready to take on the next challenge, whether it be a new offensive cross stitch pattern or making her dogs sit still for another themed photo, she is prepared for anything.