Solution to nginx truncation when PHP returns content too long

Background of solutions to nginx truncation when PHP returns too long

On Sunday, I updated my blog version to the latest version. By the way, I deployed the nginx and PHP environments again. PHP 7 is used. After the new deployment environment, you can find that the edit box cannot be displayed normally when you published a blog post.

Analysis

Check the html source code and find that the html source code is truncated. Therefore, the webpage content is not displayed completely.

The entire analysis process follows a large circle, that is, tcpdump, and network packet analysis using tcpflow. Finally, we found clues from the nginx error log.

The following information is found in the nginx error log:

06:08:10 [crit] 7042 #0: * 3 open () "/var/lib/nginx/tmp/fastcgi/4/00/0000000004" failed (13: Permission denied) while reading upstream, client: 117.72.224.240, server: www.bo56.com, request: "GET/wp-admin/post-new.php HTTP/1.1", upstream: "fastcgi: // 127.0.0.1: 9010 ", host: "www.bo56.com", referrer: "http://www.bo56.com/wp-admin/edit.php"

Error log display, Permission denied, indicating no Permission. Set this directory to 775. The webpage is displayed normally. If the content returned by PHP is too large, nginx first saves a part of the content to a text file and sends it to the client after receiving all the content.

When tcpdump is used for packet capture analysis, it is found that the nginx process sends a reset ID to the PHP process to terminate communication. Possibly, nginx closes the connection if it finds a Permission error. I just guessed that there was no verification. The figure is as follows: