Home >Backend Development >PHP Tutorial >Research on SSI issues in nginx, Research on nginxSSI issues_PHP tutorial
I feel quite happy recently. No one in this project team specializes in PHP. I am the first one to come in to do PHP ( Of course there is the front end), haha, I will design and modify a PHP framework that suits our business, haha, I feel like I will learn a lot. A few days ago, I talked about the PHP framework in front of more than 20 seniors in the group, and talked with the big guys We are discussing the PHP framework that is suitable for us. I feel that my ability to express myself is too poor. I cannot express clearly what I know. I still need my mentor to help me express it. I would like to thank my mentor Yu Honglei (Brother Lei for short) and Brother Lei. He is simply my idol. I have never seen such a profound programmer. This is for sure that he is a good technician. His understanding of technology is beyond my imagination. Brother Lei has read a lot of books and has a wide range of interests, especially in In terms of history and literature, the chat is organized and humorous, and I quote a few words from someone's article from time to time, ah! I really don’t feel that he is a technical master, more like a person like Luo Yonghao, haha. In the past two years, Brother Lei has been my goal. Read more books, speak more, and improve my ability to express myself. Otherwise, what I know cannot be Sharing it through the most direct expression is very depressing.
After so much nonsense, let’s get to the point. Today I’m going to talk about a question about SSI. Let’s first introduce SSI
SSI is the abbreviation of Server Side Include, which means server side inclusion. What I am going to talk about today is just using the include command of the SSI module in nginx. This command will include a page and then expand it in the nginx server.
What problem am I encountering? Now there is a rich text editor that requires you to save the page, enter some HTML (including the SSI include command), and then save it in the database. After saving, it also requires that it can be edited. The content in the rich text editor is required to be like this. As follows:
<html> <head> </head> <body> <!--#include virtual="/sinclude/test.shtml"--> <div>Hello World!!!</div> </body> </html>
The problem lies here, which contains the ssi command.
If accessed directly, only Hello World will be displayed! ! ! , we configure nginx as follows:
ssi on; ssi_types text/html;
At this time, if there is data with mime type text/shtml passing through nginx, nginx will go back to parse these commands, which causes a problem. I find the data in the database and return it to the client rich text editor. An error will occur. My echo content is as follows:
<!--# include virtual="/sinclude/test.shtml" --> <!--# include virtual="/sinclude/test1.shtml" --> <!--# include virtual="/sinclude/test2.shtml" -->
The page will display this form:
This makes me a little depressed, because other functions on the server must use SSI, but I don’t need it here. What should I do?
At this time, I thought of ssi_types. The setting here is text/html, and there is also a commonly used text/plain. What is this type of mime? In the browser, it will leave all the content intact. It is displayed dynamically without parsing html and css. If this type is used, nginx will not expand. Try modifying the mime before outputting:
header('Content-type: text/plain');
Sure enough, after modifying the mime, the output is consistent with the one in the database and remains unchanged:
It seems that the problem has been solved, but I didn’t expect that due to historical reasons, the content in the background edit box is returned together with other content. This is embarrassing. If it is set to text/plain, all the content will be displayed in text form. Browser, the problem is still not solved~~
At this time, I think of the nginx configuration. Since the files that need to be parsed and expanded by nginx generally have suffixes such as shtml and html, and the query database is usually php, I can reduce the use of ssi to files with suffixes of shtml and html. Take a look at the configuration, here I will move the ssi configuration information into a match, and then look at the effect,
location ~* \.(html|shtml|htm)$ { ssi on; ssi_types text/shtml; proxy_pass http://www.testssi.com; }
Create new html and php files with similar content,
<?php echo '<!--# include virtual="/sinclude/test.shtml" -->'; echo '<!--# include virtual="/sinclude/test1.shtml" -->'; echo '<!--# include virtual="/sinclude/test2.shtml" -->'; echo 'TEst!!';
HTML:
<!--# include virtual="/sinclude/test.shtml" --> <!--# include virtual="/sinclude/test1.shtml" --> <!--# include virtual="/sinclude/test2.shtml" --> TEst!!
You will find that the php access only outputs Test!!, and other content can only be seen by viewing the source code. In html, it will be parsed, and the content corresponding to the included file will be output or an error will be reported if it is not found! ! At this point the problem has basically been solved. If you try this method after work next week, it should be fine. It was ok during the test.
The copyright of this article belongs to the author iforever (luluyrt@163.com). Any form of reprinting is prohibited without the consent of the author. After reprinting the article, the author and the original text link must be given in an obvious position on the article page.