Application protocols

Reading an HTTP exchange

An HTTP request combines a method, a target, headers, and sometimes a body. The response carries a status code, headers, and an optional body. HTTP/1.1 presents these as text; HTTP/2 encodes them in frames and can multiplex streams over one connection.

A simple request

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

GET retrieves a representation. HEAD asks for response metadata without the representation body. A server uses Content-Type to describe the bytes it returns.

Status codes are categories

• 200: the request succeeded.
• 301 or 308: the resource has a permanent new location.
• 404: no representation is available at the requested target.
• 503: the service is temporarily unavailable.

Caching is explicit

Cache-Control: max-age=300 permits freshness for five minutes. no-cache requires validation before reuse; it does not mean “never store.” no-store tells caches not to store the response. An ETag is a validator, not a timestamp.

Protocol versions and encryption

HTTP/2 typically uses TLS over TCP on the public web. HTTP/3 uses QUIC over UDP. A protocol version alone does not prove that an application is secure: certificate validation, authorization, and correct handling of data remain essential.