Its job in the system
A web server receives a request and sends a response. The requested resource might be a saved file, a generated page, or data produced by an application. “Server” can describe a software role rather than one physical machine; many deployments divide the work among front-end services, application processes, databases, and caches.
How it works
A request identifies a target and a method, along with fields that describe the request. A response includes a status and metadata, and often a body. The familiar page is only one possible body. Images, style sheets, and structured data can each be retrieved through their own requests. A page can therefore depend on several services.
Status codes distinguish kinds of outcomes. A missing resource is different from an unavailable server or a network connection that never succeeds. Receiving an HTTP error still means some HTTP service answered. By contrast, a DNS failure or a broken route can prevent the browser from reaching that stage at all.
An error can still be a response
Illustrative example: a browser requests a fictional resource that the contacted web service does not have. The service returns an HTTP response indicating that the resource is missing. That differs from a failed DNS lookup or a broken connection that prevents any HTTP exchange. A message on screen may therefore come from very different stages of the journey. The example does not diagnose a particular error; it shows why naming the failed dependency is more useful than calling everything an internet failure.
What it connects to
The server’s response travels back through transport and network layers to the browser. It may come from an origin service or from an intermediary authorised to serve the content. The physical infrastructure needs electricity, cooling, connectivity, and operations; the apparently weightless web still depends on buildings and equipment.
Different places, different designs
Static sites can serve prepared documents with little request-time work. Other sites generate personalised responses or combine many backend systems. Geographic distribution, caching, and load balancing can make one domain lead to different machines. Our diagram uses one service endpoint to make the transaction easier to follow.
Sources & further reading
Original explanations informed by these sources. Diagrams are conceptual; local systems differ.
- RFC 9110: HTTP Semantics IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
- RFC 9111: HTTP Caching IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
- RFC 9114: HTTP/3 IETF / RFC Editor; M. Bishop (editor) · 2022-06 · Source & rights record
- How the Internet Works Internet Society · Not stated · Source & rights record