Answer the question
In order to leave comments, you need to log in
What is the scheme of how an http request works?
Hello, I have the following question.
Is it possible that when I make a request from the client, the server will process it, but I will not receive a response (network problems, 3g, for example)?
Those. a certain variable will be added to the database on the server, and I will think that the request failed - and I will make one more, and one more, etc.
It seems that I have been programming for a relatively long time, but somehow I never thought about it. I would be grateful for recommendations on what to read on the topic.
Answer the question
In order to leave comments, you need to log in
The question, rather, is not connected with the specifics of the http request, but with the work of the server and client at the application level.
A request sent twice will be processed twice.
To avoid such cases, there are many different options. Most often, it depends on the logic. For example, when modifying data, this behavior, most often, is not terrible (having edited, for example, your login twice, as a result we get the correct result). When inserting data, it is often enough to check whether the same data was last written to this table by this user (for example, a comment posted twice).
A more universal way is to make a signature for each form, which is attached to the user and a new one is generated for each form. After the request is processed, the entry is deleted. Accordingly, by sending the form a second time, we will see that there is no such signature, and the request does not need to be processed. This is usually done for security reasons, but as a side effect, it saves you from resubmitting forms.
Of the minuses - an additional overhead, you need to correctly handle erroneous situations. For example, update the data on the page that the user wanted to modify.
According to the HTTP specification, all requests are divided into idempotent - not changing the state of the server side (for example, GET) and non-idempotent - changing the state of the server side (for example, POST).
Further in the same standard it is written that everyone should handle non-idempotent requests very carefully - for example, it is desirable for browsers to warn users that they are giving a command to resend a non-idempotent request, and proxy servers are prohibited from re-requesting a non-idempotent request in case of incomplete success.
But in general, everything is as they said before - if the server does not specifically process this fact, and the client side repeats POSTs without hesitation, then this situation is not excluded.
On the other hand, changing any server variable significant for the logic of the application process after receiving a GET request is a clear mistake of the programmer, or rather, non-compliance with the standards.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question