preface

On Friday, I went to the toilet and got a message from my customer base. I lost a screenshot. I rushed up and asked, why can’t I edit this?

I look so fucking blind, I want to know why I can’t edit. Open the online system, find the edit popup window, press F12, switch to Network, press the save button with all your strength, thinking in my heart, xx user must be your improper operation, look at me this is not good.

The red error in network is like a slap in the face, I’m too difficult. Why? Why is there no problem when this feature has been available for over a month. All right, let’s get out of here.

screening

  • The first step

After network is enabled, only a 404 message is generated on the interface. Other interfaces are good, thinking this broken code has not been touched for more than a month, it should not be the problem of the code. Right-click and copy the interface address to the browser to open directly

This interface is a POST request, so it returns an error, but the HTTP status is still 200, because the code logic is normal

The backend code is out of the question for now

  • The second step

Because this requirement has been online for more than a month, and the test environment has been verified online. It is normal for the front end to invoke other interfaces including GET/POST

The front end code is excluded here for the time being

  • The third step

Copy the url of this interface to Postman and request it once without any arguments:

The same can be adjusted, is also the normal 200.

The exception here is the browser problem

  • The fourth step

I copy the parameters from the browser request body to Postman and try it out.

This data seems to be a little too much ah, in the mind is not the parameter problem, try it, copy to debug:

Notice that I tuned it, because I finally fixed the problem, so it works now, but when I excluded it, it returned 404

At this point, the suspect has already locked the body of the POST request. The initial suspicion is that the parameter JSON body data is too much

  • Step 5: Verify whether it is a parameter problem

Just find a POST request online and try it out with fewer parameters.

Other POST interfaces are found to be normal, and the parameters are not many. Only the interface in question contains a large number of parameters. I’m going to create a new text and I’m going to copy the parameters in and I’m going to look at the size

This was a success

This is a failure

Now that the culprit has been identified, decide that it is yours. Take this problem to Baidu and see if anyone else has the same problem

  • Step 6: It’s Nginx

With doubt to the Internet Baidu, key words:

Nginx HTTP Post body is larger than 404

Link to original text

A similar problem was found and the nGINx configuration was modified according to the schema

# Size of Buffer allocated by Nginx to request data
client_body_buffer_size  128k;
Control the size of all request packets for this server
client_max_body_size   16m
Copy the code

Restart the service and try again to resolve the problem.

conclusion

  • client_max_body_size

Client_max_body_size The default value is 1 mbit/s. It indicates the maximum size that a client can request from the server. The value is specified in the Content-Length request header. If the Request body data is larger than client_max_body_size, the HTTP protocol reports error 413 Request Entity Too Large. That is, if the body of the request is larger than client_max_body_size, it must fail. If you need to upload large files, be sure to change this value.

  • client_body_buffer_size

Nginx allocates the size of the Buffer to the requested data, and stores the data in memory if the requested data is smaller than client_body_buffer_size. If the requested value is greater than client_body_buffer_size and less than client_max_body_size, the data is stored in a temporary file first

about

  • This article originally describes an online interface 404 troubleshooting process