When a browser requests a file that the web server cannot locate, the server responds with an HTTP 404 Not Found status code. This means the server successfully received and processed the request but could not find the specified resource. If the server is configured properly, it may also return a custom 404 error page to inform the user in a more user-friendly way. These custom pages are commonly used to retain user engagement by providing links to other parts of the website or encouraging the user to search for what they were originally seeking. The request will not cause a failure in the browser itself, but it will result in either a blank error message or the display of the custom page. The 404 error is one of several standard HTTP status codes defined to handle different situations. These responses help browsers understand how to proceed or notify users about issues encountered during loading.

Yes, a single web server can host multiple websites using a method called virtual hosting. There are two main types: name-based and IP-based. In name-based virtual hosting, the server uses the Host header from the HTTP request to determine which website the client wants to access. This means multiple domain names (like www.site1.com and www.site2.com) can share a single IP address, and the server delivers different content depending on the domain requested. In IP-based virtual hosting, each website is assigned a separate IP address, and the server listens on each one separately. Name-based hosting is far more common because it is cost-effective and makes efficient use of resources. Web server software like Apache and Nginx are configured with virtual host directives or server blocks that map domains to the appropriate directories or applications on the server. This allows one physical or virtual server to support many domains simultaneously without conflict.

A single web page is often composed of multiple separate resources in addition to the main HTML document. When a browser receives the HTML page, it parses the structure and identifies references to external files such as CSS stylesheets, JavaScript scripts, images, fonts, videos, and other media. For each of these referenced files, the browser makes a separate HTTP request to the server. These additional requests ensure the complete page is rendered correctly with all intended styles, behaviours, and content. Modern browsers optimise this by making several requests concurrently using persistent connections (particularly with HTTP/1.1 and HTTP/2) to speed up loading. Some sites also serve assets from external servers or CDNs, meaning requests may go to several different domains. Additionally, a page may include asynchronous scripts that make further requests after the initial load. This modular approach to web development allows better reusability, caching, and faster updates of individual page components.

A user agent string is a line of text sent in the HTTP headers of a request that identifies the browser, operating system, device type, and other client details. For example, it might say "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/114.0.5735.199 Safari/537.36". Web servers use this information to tailor their responses to the client. For instance, they may serve different versions of a site for mobile devices, optimise images for specific screen sizes, or adjust page layouts depending on browser capabilities. In some cases, servers might block or restrict access based on certain user agents, such as known bots or outdated browsers. While the user agent can help improve user experience, it can also be spoofed by malicious users or automated scripts. Developers can also use this information in analytics to study which platforms are most commonly used by visitors and optimise web content accordingly.

When a web server needs to direct a client to a different resource, it responds with an HTTP redirection status code, typically 301 (Moved Permanently) or 302 (Found/Temporary Redirect). Along with the status code, the server includes a "Location" header that specifies the new URL. Upon receiving this response, the browser automatically initiates a new request to the given URL without requiring user intervention. This redirection process is invisible to users but is essential for scenarios like moving content to a new domain, enforcing HTTPS instead of HTTP, or restructuring a site’s navigation. In the case of a 301 redirect, search engines treat the redirection as permanent and will update their indexes accordingly. A 302 redirect, on the other hand, is temporary and tells search engines not to update their indexes. Browsers often cache redirect responses to improve load times, but developers must manage caching behaviour carefully to avoid redirect loops or stale paths.