Concept and mechanism
An HTTP request describes an operation on a resource through a method, target, fields, and possible content. The URL includes information guiding connection and service selection. An origin combines scheme, host, and effective port; sharing an IP or certificate does not merge distinct origins. On a server with several virtual hosts, testing the IP directly can select the default page. Retain the sent name and observed listener before comparing results. With HTTPS, TLS identity adds another check covered in its own lesson. DNS resolution and transport connection are necessary steps in many journeys but do not confirm that the intended application was selected.
Guided application
Distinguish the sent format from response preferences. Content-Type describes the content media type; Accept communicates acceptable response formats. Content-Encoding can indicate gzip, while chunked frames an HTTP/1.1 transfer. Do not treat these fields as synonyms. In a fictional case, a check receives 200 and a login page when it expected batch data. The test needs authentication, content, and freshness criteria defined for the authorized journey. Client exit status also differs from HTTP status: curl can complete an exchange containing 503 without failing by default. Record both alongside the business outcome needed for the operational decision.
The address responds, but Host selects the default page: connectivity does not validate the portal.
Common pitfalls
IP as complete identity; Accept as sent-body format; zero exit status as a healthy service.
Related topics: Methods, statuses, and controlled retries · Caching, variants, and validation · Versions and message framing
Establish that the test reached the correct service and representation.
Reference: HTTP Semantics · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance