HTTP, TLS, and reverse proxies

Read the request and response separately

HTTP gives meaning to a request: method, target, headers, and sometimes a body. For a personal static site, a conceptual HTTP/1.1 request might be:

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

GET requests a representation, /notes.html is its path, and Host identifies the requested host. DNS resolved the name earlier; it did not choose this path. HTTP/2 and HTTP/3 encode messages differently, but methods and status meanings remain relevant. HTTP/3 uses QUIC over UDP; do not assume every HTTPS request is TCP.

An illustrative response begins:

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

<h1>Learning notes</h1>

The blank line separates headers from the body. Content-Type describes the representation; cache instructions affect reuse. 200 reports this request's HTTP success, not that every linked image or business operation works. HEAD requests response headers without a response body; some endpoints implement GET but not HEAD. POST often submits data, while PUT and DELETE have different intended semantics. Retrying an operation requires knowing whether repetition can duplicate effects.

Observe one bounded public request

With curl installed inside Linux:

curl --head --connect-timeout 3 --max-time 10 https://example.com
printf 'curl status: %s\n' "$?"

Record the status line and two headers actually returned; output varies. --connect-timeout bounds connection establishment and --max-time bounds the whole operation. Curl's exit status is distinct from the HTTP status: by default an HTTP error response can still be a successfully completed transfer. A TLS or connection error generally prevents a normal HTTP response. Do not disable certificate verification to force the request through.

TLS protects a connection to a verified peer

TLS negotiates keys for encryption and integrity. For a typical HTTPS server connection, the client checks the certificate's chain to a trusted authority, validity period, and suitability for the requested hostname. The client clock matters. SNI tells the server which hostname the client wants so a shared endpoint can select an appropriate certificate; a Host header alone cannot fix a TLS hostname mismatch.

TLS does not prove the site content is correct, or hide all traffic metadata. A successful handshake to a proxy only establishes that connection; the proxy may use another TLS connection—or plain HTTP—to its backend according to configuration. curl -k skips verification and is not a certificate repair.

A proxy adds another request leg

Consider a proposed site: browser → HTTPS reverse proxy → local static server. A reverse proxy receives client requests on behalf of an upstream server. A load balancer can distribute requests/connections among several upstreams. A Layer 4 balancer works with transport connections; a Layer 7 proxy can use HTTP information such as paths. Neither is required to begin serving your local single-site fixture.

For a real existing proxy, compare the documented direct upstream request with the proxied request. If the direct request works but the proxy gets 502, inspect upstream address/protocol, connection reuse, and proxy logs. If both return the same missing-resource response, investigate the requested path before rewriting network policy.

Health checks, balancing algorithms, and connection draining matter when adding multiple backends. A green shallow health check does not guarantee every request succeeds. Forwarded client-IP headers must only be trusted from configured proxies; clients can otherwise supply misleading values. Each hop also has its own timeouts.

If a submitted operation times out, did the server definitely do nothing? No. It might have completed before the response was lost. Duplicate-safe request design belongs to that application. For this path, keep the probe read-only and compare response content as well as status. The next bite combines these checks into diagnosis.

Sources

Primary references: curl options↗; HTTP semantics↗.