HTTP request and response

What it means

An HTTP request asks a server to perform an action on a target resource; an HTTP response describes the result. The request has a method (such as GET or POST), a target and headers. It may have a body. The response has a status code and headers, and may have a body. Headers carry metadata; they are not all instructions to the server. HTTP semantics

A URL identifies where the request is directed, but its fragment (the part after #) is not sent as the HTTP request target. The browser or client first establishes the relevant connection; with HTTPS, TLS protects the HTTP exchange in transit. HTTP alone does not promise encryption.

Try it

Example — assemble an HTTP exchange locally. Choose GET or HEAD, a synthetic path and a supported media type, then run the local exchange. Inspect a message part to connect the request start line, fields and body with the corresponding response elements. Nothing is sent to a server.

The fixture contains / and /guide; /missing is a valid question for an absent route. Compare GET /guide with HEAD /guide. Both describe the same selected representation, but HEAD has no response content. Its Content-Length can describe the corresponding GET representation; it does not mean that many body bytes were transmitted in the HEAD response. Method semantics

The Accept control demonstrates a server's declared negotiation policy, not a rule that every server must produce JSON. Unknown methods, control characters, arbitrary URLs and unsupported target syntax are rejected. The path field accepts only the displayed bounded characters and never accepts credentials or request headers. Reset restores GET /guide, HTML and the start-line explanation.

The displayed exchange is an HTTP/1.1 teaching representation with ASCII bodies. HTTP/2 and HTTP/3 frame messages differently. GET/HEAD request content, informational responses, streaming, compression and connection reuse are outside this small scene. HTTP/1.1 request target and framing

What happens to a request?

1. A client derives the origin and request target from the URL. DNS name lookup, connection setup and TLS negotiation (for HTTPS) are separate concerns.
2. It sends the method and fields. An API might send a JSON body with a POST; a normal GET often has no content. Do not infer that every request has a body.
3. A server, application or intermediary determines a result: for example 200 OK, a redirect, 404 Not Found, or a server failure.
4. The client interprets status, response headers and any received content. A 204 No Content response deliberately has no body; a HEAD response also has no message body, even when headers describe the representation. Message framing

When it helps

In browser developer tools, select a request and inspect its URL, method, status, request and response headers separately. A successful TLS connection does not imply an HTTP 200; a completed HTTP exchange may legitimately return 404. A response body may be JSON, HTML, an image or nothing. Caches and proxies may participate, so the response did not necessarily originate from the application itself.

Avoid pasting authentication cookies, bearer tokens or customer data into troubleshooting tickets. Share only sanitized headers and the status needed to reproduce a problem.

In practice

Start with HTTPS and TLS to understand connection protection. For a real 404, follow HTTP 404 troubleshooting; for a proxy-side 502, use HTTP 502 troubleshooting. HTTP status, DNS answers and TLS validation are three different observations.

Key takeaways

Separate the requested action from the server's outcome. Read fields in the context of their request or response, and do not infer transmitted body bytes from a status or header alone. When diagnosing a real exchange, preserve method, target, status and representation context without exposing private headers or content.