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?
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 | METODO CAMINHO PROTOCOLO/VERSAO | PROTOCOLO/VERSAO STATUS
| 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 | |
CORPO | DADOS DO PEDIDO | DADOS DA RESPOSTA
MÉTODO is GET , POST , PUT , DELETE , but is not limited to these. In addition, you can extend the protocol and define specific methods for the application you are using (and need to do the corresponding server-side method).
What are the HTTP request methods, and what is the difference between them?
When should I use GET function and when should I use POST function?
CAMINHO is the one that comes after the URL. Be just a / slash or be a path to the resource as /blog/47894/como-fazer-amigos-e-influenciar-pessoas . You can include a query string , as ?mode=json at the end.
Important to note that anchors are not part of the way. At an address like /index.html?order=date#details , the path is just /index.html?order=date .
PROTOCOLO/VERSAO is usually HTTP/1.1 , very rarely HTTP/1.0 , and now it works on HTTP/2.0 , which is already understood by some servers.
About this, there are some details here:
When you access a web site as www.exemplo.com.br , your browser resolves the address (turns www.exemplo.com.br 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
Host: www.exemplo.com.br
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
<html>...
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
Host: www.example.com
nome=gato&senha=secret
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
Host: www.example.com
DADOS_DO_ARQUIVO..........
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:
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
Host: www.seusite.com
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
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
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.
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).
Your question suggests two paths:
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