Shulou(Shulou.com)06/02 Report--

In GET request using body instance analysis, many novices are not very clear about this, in order to help you solve this problem, the following small series will explain in detail for everyone, there are people who need this can learn, I hope you can gain something.

The story starts with a bug. Someone asked me today why the request sent to the backend was 400, and I said it must be the wrong parameter. You check to see if the GET and POST methods are written correctly, or the fields are not correct. It is nothing more than these problems. Then he said that he had checked it and there was no problem; I didn't believe it, but looking at the request sent by the front end, it seemed that there was really no problem:

I said that since this is the case, then it must be written incorrectly on the backend, but the backend said that he had already tested it with postman, and there must be no problem. That's interesting. So I came up with the back-end code:

As expected, the backend took the parameters in the GET request as the body content, and changed @RequestBody to @RequestParam, which should be fine.

It was a simple question, nothing to say, but then they asked me why I couldn't use body in GET requests. I think that usually no one adds body to GET requests, and I have always heard that it is not good to use it. But why not? So I looked up some information and finally went to RFC to flip through it. See what the official says:

[RFC7231] A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

It means that you add body to GET request is not in line with the specification, do not guarantee that all implementations support (mainly previous implementations, because there have been corresponding regulations in the past), if there is any problem, don't blame me for not reminding you. And it is said that the old version of postman does not support the addition of body in GET requests, and it is also recently added support; so if you want to put it in the past, there will be no such problems. The previous postman simply cannot send GET requests with body.

But this is not mandatory. I think many people emphasize that GET requests should not carry the request body, and the server should ignore (or discard) the request body of GET requests. This article is indeed valid and comes from the following sources:

[RFC2616] A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

A request like HEAD MUST NOT have a message body:

[RFC2616] A message-body MUST NOT be included in a request if the specification of the request method does not allow sending an entity-body in requests.

RFC2616 is outdated. Now the saying has become like this, even SHOULD has been directly removed, and the requirements are more relaxed:

[RFC7230] Request message framing is independent of method semantics, even if the method does not define any use for a message body.

Could it be because there were so many wrong people that the wrong ones became the right ones? But even if this is the case, it is not a reason to add a body to a GET request.

This problem was solved. But I saw that when all the great gods on the Internet talked about GET plus body, they also mentioned that adding body to GET would cause the cache mechanism to fail. GET is designed to identify resources by URIs, and if you let it carry data in the request body, then the usual caching service fails, and the URI cannot be used as a cached Key. "I initially thought it was a cache configured on the server, such as Nginx's cache mechanism, but later it turned out that this was not the case. This caching, presumably referring to preloading and post-storage, involves the "security" of a network request. If it's not secure, it obviously can't be cached.

What is the difference between GET and POST? It's a complicated question. In short, the difference between "safe" and "unsafe." What is security? No responsibility. What is unsafe? May be held accountable. For example, clicking on a link to agree to an agreement is obviously unsafe because of the liability involved. If GET is used, it violates the specification that GET should be used for secure requests. Because the browser may be preloading the page without your knowledge (because it's a "safe" GET request), it's the equivalent of you agreeing to a protocol without your knowledge, which is obviously something we don't want to see. In contractual design, breach of contract has serious consequences. The browser preloads a secure GET request according to the contract, but this is itself insecure, and the consequences are naturally borne by the person who breaks the contract (who designs the request as GET).

The emphasis is on "safe" rather than side effects, as is conventional, because requests with side effects do not mean unsafe; for example, a server has a function that displays the number of visitors, which can be done with GET. Although each access sends a request to change the server state (counter), the user is not responsible for this request, which is safe. As for what GET request URL has length limit (later it turns out that there is no), what GET request URL can not have Chinese (or non-ASCII bar), are only the difference in implementation; from the original design, the difference is not here.

Of course, these are purely theoretical things. If RESTful specifications are followed and semantic GET/POST requests are used, these problems are naturally eliminated. Because queries are generally safe; that's what GET does.

It's interesting to say, after studying for so long, I often mention RFC, but I don't know what RFC is. This time I checked it together. Although I always feel that this is influenced by the interpretation of the 6f noun... it turns out to be called "Request For Comments".

Did reading the above help you? If you still want to have further understanding of related knowledge or read more related articles, please pay attention to the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.