An Apache log error was found when the greeting card was preparing for the holiday day. I would like to summarize the process from positioning to solving the problem, hoping to inspire you to locate and solve the problem on the current network.
Symptom: During a period of time, a large number of Apache card error logs were found, because the following errors were encountered, but the Internet page did not have the actual effect (so it is difficult to locate ).
[Tue Feb 03 00:01:00 2009] [Error] [client *********] file does not exist: /data/web/ecard/ecard_new/htdocs/{ecard_image_small}, Referer: http://ecard.qq.com /(.. omitted ). PHP
[Tue Feb 03 00:01:01 2009] [Error] [client *********] file does not exist: /data/web/ecard/ecard_new/htdocs/{ecard_image_small}, Referer: http://ecard.qq.com /(.. omitted ). PHP
Locating Process:(Inspired by constant questions + excluded Solutions)
1. If you see such a 404 error, check whether the strings in the path of some greeting cards are incorrectly pieced together, leading to access failure. However, on the Internet page and temporarily added logs, string Regular Expression filtering, etc., the returned item path is obtained normally, and no corresponding error log is displayed in the background. Therefore, this suspicion is ruled out.
2. Considering that the macro {ecard_image_small} is replaced by the tphplib library, the possibility of library function macro replacement failure is also ruled out;
3. Then the problem is concentrated on the macro {ecard_image_small} content,Since the item path is correct, the string is normalWhy is the page not properly replaced?
4. Try the template page and foreground PHP in two ways at this time. At that time, a proposed to replace the table with a DIV, so B was asked to temporarily use a div template page. After the replacement test, the replacement still encountered an error, even the IMG tag that references {ecard_image_small} is blocked. the problem persists. This means that the macro is output in advance before the template page is loaded, so the template page relevance is excluded.
Cause:
Finally, only the possibility of PHP code is left. After careful check and experiment, we found that the cause was that the macro {ecard_image_small} content was not properly filled due to incomplete data obtained through the background interface, the macro is not initialized at this time, so Apache directly outputs the DocumentRoot + macro name to the page.
The file does not exist:/data/web/ecard/ecard_new/htdocs/{ecard_image_small} error is generated because the image path does not exist in the page request.
Solution:
1. the PHP code on the Web end is added with the macro initialization code, so that {ecard_image_small} is initialized to a default image address, so that even if the received data is incomplete, no 404 error will be generated (initialization cannot be blank here, because it is an image !)
2. the server-side Code fixes the problem of incomplete background interface data, ensures that the returned protocol string is a qualified protocol string, and discards or fixes the invalid code. Generally, some special characters may cause separation errors, or the DB data itself is incomplete and must be processed by the server before being returned to the interface for output.
The above shows the whole process of solution. Although it is a small problem, it takes a lot of effort to solve it. The difficulty lies in:
1. log errors found on the internet, user functions are not affected, and no error is displayed on the page, resulting in confusion;
2. The error is hard to reproduce and has never been known under what conditions. Later, during the internal network tests, it was very difficult to locate only a few numbers;