How does the HTTP protocol process the requests?


HTTP methods are used to send and receive data from the server, such as GET (retrieve data) and POST (send data).

Following the above definition to understand very well the purpose of GET and POST , however I have a pertinent doubt as to how HTTP processes the request according to the HTTP verb.


How does the HTTP protocol process (under the wipes) the requests, ie how does the client and server communication through the request methods?

asked by anonymous 29.12.2016 / 14:20

3 answers


First of all, it is good to understand HTTP as a series of format conventions to be used over a common TCP connection. In principle it is a stateless protocol in which you basically send one text and get another one back.

In other words, HTTP does not process anything, but defines a format. It is the responsibility of the application that meets the request to process the data, and provide a consistent response to the protocol.

The Wikipedia even has a reasonable definition of HTTP, but I will try to highlight the most relevant points to the question in a way simpler soon after.

If you want to delve deeper into the specification after understanding the basics, follow the link to the W3 Consortium , which is responsible for defining and regulating the standard officially:




An HTTP request is characteristic of this format:

            | REQUISIÇÃO                      | RESPOSTA
            | Cabeçalho 1: valor1             | Cabeçalho 1: valor1
            | Cabeçalho 2: valor2 ...         | Cabeçalho 2: valor2 ...
            | Cabeçalho N: valorN             | Cabeçalho N: valorN
linha vazia |                                 | 


When you access a web site as , your browser resolves the address (turns into an IP address, using DNS).

Next, it connects via TCP to the obtained IP, in principle on port 80 (which is the default of HTTP, being 443 the default of HTTPS). Once connected, it will send something like this, verbatim:

GET / HTTP/1.1

And that's all. Assuming there is a page in the requested address, you will get something like this back:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 351
Connection: close


Note that it's almost the same thing, except that in the answer instead of METODO CAMINHO PROTOCOLO you have PROTOCOLO STATUS DESCRICAO_DO_STATUS in the first line.


Once you understand the basic part of the protocol, let's see what changes if instead of a GET we have a POST . In the case of POST we have some more information to send, and as described above, we use a blank line to separate the contents of the header:

POST /formulariodeinscricao.html HTTP/1.1


Note that the key word here is POST , the information for the first line, and in the request body (after the blank line) we have the values sent. In case I used the most common form of web forms, the format may vary depending on the case.

If it were a file upload with PUT it might as well be:

PUT /upload.html HTTP/1.1


Test Tool

There are some online tools that help you investigate and "debug" HTTP requests, one of them is this API, with several endpoints, which show a diversity of information, which helps a lot to test the sending part and the receipt of your application:



More references


What is a "stateless protocol," such as HTTP?



29.12.2016 / 15:06


As the Bacco already said in the comment protocol is a #


pro · to · co · lo | ó |   male noun

  • Form.

  • Minutes of conferences held between ministers plenipotentiaries of different nations, or between members of a congress   international.

  • Regulation that is observed in some public forums.


    "protocol", in Dictionary Priberam da Língua Portuguesa [online],   2008-2013, link [consulted at   29-12-2016].

    In our case what most fits is the fourth item. It is a set of rules that indicate how communication between computing entities will "talk". They need to speak the same language, they need to use the right words in the right places to understand each other clearly, completely and unambiguously. "HTTP Protocol" is a pleonasm since the acronym stands for HyperText Transfer Protocol or HyperText Transfer Protocol.

    Specifically HTTP is something that regulates the application layer of networks using web technologies. These rules are set by the World Wide Web Consortium .

    HTTP is basically a simple text (HTTP 2 can be binary) with a header saying what it is and then a content that it wants to communicate effectively (before it had to be always text, then binary content, as an image , it needed to be converted to text). This is already part of what the protocol says. What this header must have, what is required, what is optional, what should be in a request and what should be in a response, even define these terms, all this is in the protocol. Among the rules is the indication of what to do with error cases, the format of each part, etc.

    Of course among these rules is what to do with caba field, each verb, error codes, etc.

    A list of regulated fields is on Wikipedia .

    Request header example:

    GET /hello.htm HTTP/1.1
    User-Agent: User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
    Accept-Language: en-us
    Accept-Encoding: gzip, deflate
    Connection: Keep-Alive

    Note that the protocol does not want to know anything about how the communication itself is being made, it is another protocol problem that is likely to encapsulate the HTTP packet. HTTP only takes care it says it's there and down here.

    HTTP response example:

    HTTP/1.1 200 OK
    Date: Thu, 29 Dec 2016 12:02:52 GMT
    Server: Apache/2.2.22 (Win32)
    Last-Modified: Wed, 28 Dec 2016 13:16:38 GMT
    Content-Length: 88
    Content-Type: text/html
    Connection: Closed
    <h1>Hello, World!</h1>


    An application that wanted to conform to HTTP should follow these rules. In some cases the application and the environment where it runs need to process other protocols in different layers, this is called the OSI model .

    The application receives this "text" and processes it. That is, he does a parsing of what he finds there and decides what to do with the information (which becomes the semantic analysis ). There is also the sending of "text", there he just has to assemble it according to the rules, put every thing in the necessary order, jumping line, having the expected texts, etc. This will be processed on the other side. In general there is a client that makes the requests and a server that provides the answers.

    As the application will do this is her problem, she just needs to respect the rules.

    More specific questions fit.

    29.12.2016 / 15:04

    HTTP is the theoretical model for communication of hypertext systems. Porcally comparing, it is a list of rules so that two foreigners can have successful communication. The total communication is all architected in a model called OSI (Open Systems Interconnection). HTTP I believe it acts on the third layer (correct me).

    • 7 Application layer;
    • 6 Presentation layer;
    • 5 Session Layer;
    • 4 Transport layer;
    • 3 Network layer;
    • 2 Link layer of data;
    • 1 Physical layer.

    Your question suggests two paths:

    • 1) How does the hardware handle data communication?
    • 2) How does the server receive data that the operating system receives from the requests?

    The first question is a question of electrical engineering, and I believe it is not part of the stack overflow culture. The second question is related to understanding how the operating system works. There is the kernel, which has closest communication with the hardware, and the auxiliary programs, which in fact make the system 'operational'. The kernel receives the data from the hardware, processes it in its auxiliary programs, until it reaches the seventh layer of the OSI model. The data is organized into packages, which has a header with destination and source information. Here, at this point, GET / POST requests are either approved or refused for physical reasons. Approval or denial of data via GET / POSTs for logical reasons should occur from the fifth layer onwards. Because of this delicate and direct relationship, an operating system is relevant to security. If I used some non-genuine concept from the engineering point of view, it was to be didactic. Feel free to edit and fix it.

    Recommended Reading: link

    29.12.2016 / 15:04