What Is an HTTP Header?

Scrapeless Web Unlocker accepts documented request headers and returns public web content that applications can inspect alongside HTTP response context.

An HTTP header is a field attached to an HTTP message. A request field may tell a server what representation the client accepts or provide a credential. A response field may describe the returned content, caching policy, or a state update. Headers sit beside the message body; they do not replace it. The body might contain HTML, JSON, an image, or nothing at all.

The word header is singular in a question but a real exchange usually contains many fields. Understanding who sent each field and how the recipient interprets it prevents common mistakes: treating Accept as proof of Content-Type, assuming a 200 response is the desired page, or logging a secret because it traveled in metadata. This guide uses a field-by-field reading approach.

Where Headers Fit in an HTTP Exchange

A client sends a request with a method and target, followed by fields and sometimes content. The server responds with a status, its own fields, and sometimes content. The HTTP semantics standard defines fields as extensible message components and distinguishes their role from the representation. A field name is case-insensitive, so Content-Type and content-type refer to the same registered field.

Headers carry instructions and descriptions, not a universal truth about the application state. A server can set Content-Type to text/html while returning a login page, access notice, or ordinary article. A cache can serve a representation whose metadata reflects a previous origin response. A gateway may add its own fields. To identify what the application actually received, inspect the complete exchange and the returned content.

HTTP versions encode messages differently on the wire. HTTP/1.1 uses textual field lines; HTTP/2 and HTTP/3 have their own framing and header compression. Application code generally works with field names and values after the transport layer decodes them. The HTTP/1.1 message specification is useful when reading a raw trace, while the semantic definitions remain relevant across versions.

Request Fields a Client Commonly Sends

Accept states which response media types a client is willing to receive. Accept-Language can express language preference. User-Agent identifies client software, though servers should not treat it as authentication. Authorization or a provider-specific key field presents credentials according to the service contract. Content-Type on a request describes the body being sent, which matters for JSON and form submissions. Each field has a different purpose and none can be inferred reliably from a neighboring field.

For Scrapeless REST requests, the key protection guide documents x-api-token as the credential field for relevant endpoints. The Web Unlocker quickstart documents the request structure, including actor and input fields, and describes optional custom headers for the target request. Do not confuse the header authenticating your call to Scrapeless with a header you ask Web Unlocker to send to a public target.

Only send fields with a reason. Copying a browser’s entire header set into a script can create inconsistent values, expose a cookie, or couple the script to one browsing session. If the target has an approved public interface, follow its documented request contract. If a request fails, inspect the actual status and body rather than adding increasingly elaborate headers without evidence.

Response Fields That Change Interpretation

Content-Type tells a client how the returned representation is labeled. A JSON parser should not be invoked blindly on text/html. Content-Encoding describes coding applied to the representation. Cache-Control expresses caching directives. Location commonly appears on a redirect response and points to another target. Set-Cookie can instruct a browser or cookie-aware client to store state under defined rules. The message status and fields need to be read together.

A response can include an ETag or Last-Modified value that helps a client make a conditional request later. Those validators do not tell a scraper whether a product price is accurate; they describe a representation version or modification context under HTTP rules. Likewise, a 304 response has meaning only with a prior stored representation. A standalone 304 body is not a fresh page to parse.

Some fields are governed by browser security policy. Access-Control-Allow-Origin can affect whether browser JavaScript reads a cross-origin response, but it does not decide whether a server-side HTTP client can connect to the host. The browser CORS guide explains this boundary. When debugging, name the layer: browser enforcement, network response, application authorization, or page content.

Reading Values Without Damaging Their Meaning

Do not split every header value on commas. Some fields use list grammar, while others contain dates, quoted values, or structured components with their own syntax. Multiple field lines can be combined for some names but not for all; Set-Cookie is a familiar special case. Use an HTTP library that preserves the semantics you need, then apply the individual field definition. Treat a field you do not understand as data to inspect, not a string to normalize aggressively.

Header names cannot be used as a proxy for trust. User-Agent can be set by a client. Forwarded or X-Forwarded-For fields can be inserted by a proxy and must be interpreted only within a trusted proxy configuration. A custom request ID can help trace a call, but it does not authenticate the sender. Security decisions require a validated connection and an application-specific trust boundary.

Credentials deserve special handling. Avoid writing Authorization, Cookie, or x-api-token values to ordinary request logs. If the application needs diagnostics, record whether the field was present and a safe request identifier. Redact both outgoing and incoming traces where session state can appear. A field’s position in HTTP does not make its contents less sensitive.

A Practical Inspection Sequence for Web Data

Start with the final URL after redirects and the HTTP status. Then read Content-Type and other fields that affect body interpretation. Inspect a small, safely captured part of the body for a marker unique to the expected page. A response can be syntactically valid HTML and still be a consent screen, a login prompt, or an access-denied page. Only after confirming page identity should a parser select business fields.

When comparing a command-line fetch with a browser, inspect both request and response sides. A browser may send cookies, preferences, and navigation context that a simple client lacks. It may also execute JavaScript after the first document response. A different returned body is evidence to investigate; it is not proof that a single missing header will reproduce the browser state.

The Web Unlocker product page describes public-page retrieval and optional rendering. The related cURL header guide shows how to inspect and send fields manually. Use those tools to establish a narrow request contract: which fields are required, which are merely defaults, and which content marker proves the response is useful.

Conclusion

An HTTP header is a named message field with a defined purpose and field-specific syntax. Reading it correctly means knowing which side sent it, how its value is interpreted, and what the body actually contains. For web data work, header checks support content validation; they cannot replace it.