HTTP request and response: how the browser talks to the site

Useful to know

When we open a page, the browser does not receive a ready-made picture of the site. It looks for resources from which it builds what is shown: document, styles, images, and other data. HTTP sets the rules for this exchange between client and server. The client sends a request, and the server returns a response. Thus, a single visible page can result from multiple individual conversations, rather than from a single indivisible transfer of everything. This explains why the text sometimes appears before the pictures. [1]

The query specifies what action is requested and to which resource. The GET method usually serves to obtain a representation of a resource, and POST is often involved in sending data. There are more headers that convey additional information, and upon appropriate body requests with content. The method and the address should be read together. The same path in the application may be involved in different actions, so the address itself does not describe the entire exchange. [2]

The answer has status, headers, and a possible body. The status communicates the result of the processing, while the body may contain a HTML, image or other data. It is important to distinguish the transport result from the displayed words: a page labeled for a problem may technically have been sent with a successful status. For diagnostics, both are looked at. The mere presence of some text in the window does not prove whether the server has correctly labeled the output of the request. [2]

There may be intermediaries between the browser and the application, for example proxy servers. They participate in the transmission and processing of individual messages. [1] Let's imagine a catalog where the document arrives but a picture is missing. This does not necessarily mean a general failure of the entire site. It is more useful to check the exact request for the photo: what address was requested, what response was received, and whether it contains the expected data type. Thus, the great impression of a problem becomes a concrete verifiable case.

The Network section in the browser tools allows these messages to be monitored. In HTTP/1.1, the structure is rendered as a starting line, headers, and content; newer versions use a different transmission while retaining the main meanings. [2] For a beginner, this is convenient: you don't need to know every detail of the network protocol first to recognize which query failed. It is enough to follow the logic of the conversation and the relationship between the requested and the returned.

A useful first habit is the problem of describing exactly: which resource, which method, what status, and what content. Then two loadings or two addresses can be compared under the same conditions. This is more informative than the general claim that the Internet is slow or the page is broken. Understanding the query and answer gives a basic vocabulary for working with sites, whether one is writing code, managing content, or checking a move to another server.