HTTP Common Method Properties

Tram Ho

Recently, people have been talking a lot about HTTP Requests, which everyone knew when they first joined IT. But the more I read it, the more I find it vague, seeing what I know is not sure anymore. Searching for documents online is also afraid of the fact that some of the novices have lost their eyes. Reading Mozilla documents, they also refer to IETF’s products, so they should read from the source for sure. If there is anything wrong with translating, please teach me and “forgive” 😄

The following article translates from RFC 7231, section 4.2: Common Method Properties

RFC 7231 Hypertext Transfer Protocol (HTTP / 1.1): Semantics and Content

Section 4.2: Common Method Properties

Before going to this section, I have summarized the list of HTTP Methods ( Section 4.1: Principle does not translate)

4.2.1 Safe methods

Request methods are called “safe” if they are themselves defined as read-only. This means the client does NOT request or expect any changes on the servers. Therefore, when safe methods are used, it is expected that it will not cause any errors to the server, not cause data loss in the system or create any burden on the server.

This definition of safe methods does not prohibit actions that are potentially harmful to the system, are NOT read-only by themselves, and may cause side effects. However, it is important that the client does NOT expect any additional server side processing and is NOT responsible for those processes. For example, regardless of the request method, most servers store the request information in the logfile every time the response is completed. This is considered a safe behavior, although logging the file may cause the hard drive to crash and the server to crash. Similarly, an initial goal request is to choose to advertise on the website, which can cause the side effect of paying an additional fee for the advertising account.

Based on the above definition, the following methods are considered safe: GET, HEAD, OPTIONS, and TRACE.

The goal of distinguishing safe and unsafe methods is to allow the process of automatically fetching data (spiders) and improving the performance of cache (pre-fetching) that can run without worrying about causing system errors. It also allows the user agent to apply binding measures to automated processes that use the unsafe method when processing potentially harmful data.

The user agent SHOULD distinguish between safe and unsafe methods and warn users, for example letting them know that an unsafe action is about to be performed.

When the system developer allows the action to be performed via the request parameter, that unit is responsible for unifying the actual handling with the meaning of the method. For example, quite a lot of web applications allow you to insert actions into parameters, for example “page? Do = delete”. If the result of this request is to perform an unsafe action, the administrator MUST disable or disallow this action, as long as it uses the safe method. Failure to do so will result in bad consequences for the system, automated processes can execute GET to the entire URI involved and cause bad effects.

4.2.2. Idempotent Methods

Idempotent: Look up the dictionary as “Progressive”, generally meaning “Don’t change the value after multiplying itself”

A method is considered to be “idempotent” if its effect on the server does not change even if it is called once or repeatedly. With this definition, the PUT, DELETE and safe methods are considered “idempotent”.

Like the definition of the safe method, the idempotent’s characteristic is to affect only those parts that the client requests, and the server is comfortable to log, save version history or deploy non-idempotent handlers to indempotent requests. .

The idempotent is separate because it can be repeated automatically, in case the connection between the client and server is closed before the client can read the response from the server. For example, if the client sends a PUT request and the connection is disconnected before receiving the response, the client can make a new connection and make the idempotent request. Because repeating the request will produce the same desired result on the server, so even if the first request succeeds, the response between the two times may also be different.

Cacheable Methods

The method is considered “cacheable” if its result is allowed to be reused in the future. Details refer to RFC7234 . Typically, a safe method that can operate without depending on decentralization would be cacheable. This definition allows GET, HEAD, and POST to be cacheable, although usually the implementation of the cache only supports GET and HEAD.

Personal opinion

The translation only translated part of the docs, the main part 4.3. Method Definitions is for readers to research by themselves. I also personally experienced a few projects, the most bloody lesson is

NEVER CREATE / UPDATE RECORDS WHEN REQUEST METHOD IS GET

(Not to mention the log access log here)

I have met a few times already, it is very good … Hope you can reflect on the dangers of this.

Chia sẻ bài viết ngay

Nguồn bài viết : Viblo