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 — two messages for a fictional document. These readable HTTP/1.1-style samples are illustrations, not an actual captured request or live check. Header values and framing are simplified.

Request:

GET /guide HTTP/1.1
Host: www.example.com
Accept: text/html

Response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=60

<p>Welcome to the guide.</p>

The blank line separates headers from content. GET requests /guide; Host identifies the authority for the HTTP/1.1 server. 200 is the response status, not a second request. The HTML following the response headers is its example body. This is not an exact byte-for-byte example with framing headers. In HTTP/2 and HTTP/3, the same semantics use different, binary message framing instead of these textual start lines. HTTP/1.1 format

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.