Heim > Artikel > Backend-Entwicklung > Forschung zu SSI-Problemen in Nginx
Ich bin in letzter Zeit ziemlich glücklich, dass sich niemand in diesem Projektteam auf PHP spezialisiert hat (und natürlich auf das Frontend), haha Unser Geschäft, haha, ich habe das Gefühl, dass ich vor ein paar Tagen vor mehr als 20 Senioren in der Gruppe über das PHP-Framework gesprochen und mit den Experten darüber gesprochen habe, welches PHP-Framework dafür geeignet ist Ich habe das Gefühl, dass meine Ausdrucksfähigkeit zu gering ist und ich nicht klar ausdrücken kann, was ich weiß. Ich möchte auch meinem Mentor Yu Honglei (kurz: Bruder Lei) danken. . Bruder Lei ist einfach mein Idol. Er ist auf jeden Fall ein technisches Genie, das meine Vorstellungskraft übersteigt Sein Themenspektrum, insbesondere in den Bereichen Geschichte und Literatur, ist organisiert, humorvoll und er zitiert von Zeit zu Zeit ein paar Zeilen. Ich habe wirklich nicht das Gefühl, dass er ein technischer Meister ist, sondern eher eine Person wie Luo Yonghao. In den letzten zwei Jahren war es mein Ziel, mehr Bücher zu lesen, mehr zu sprechen und meine Ausdrucksfähigkeit zu verbessern . Ansonsten kann das, was ich weiß, nicht sein. Es ist sehr deprimierend, es durch den direktesten Ausdruck zu teilen.
Nach so viel Unsinn kommen wir zum Punkt. Heute werde ich über eine Frage zu SSI sprechen. Lassen Sie uns zunächst SSI vorstellen
SSI ist die Abkürzung für Server Side Include, was bedeutet, dass ich heute nur über die Verwendung des Include-Befehls des SSI-Moduls in Nginx sprechen werde der Nginx-Server.Auf welches Problem stoße ich? Jetzt gibt es einen Rich-Text-Bearbeitungseditor, der erfordert, dass Sie die Seite speichern, etwas HTML eingeben (einschließlich des SSI-Befehls include) und sie dann in der Datenbank speichern. Nach dem Speichern muss der Inhalt auch bearbeitet werden können Der Rich-Text-Editor muss wie folgt aussehen:
<html> <head> </head> <body> <!--#include virtual="/sinclude/test.shtml"--> <div>Hello World!!!</div> </body> </html>Das Problem liegt hier, das den SSI-Befehl enthält.
Bei direktem Zugriff wird nur Hello World angezeigt! ! ! , wir konfigurieren Nginx wie folgt:
ssi on; ssi_types text/html;Wenn zu diesem Zeitpunkt Daten mit dem Mime-Typ text/shtml durch Nginx geleitet werden, analysiert Nginx diese Befehle erneut, was zu einem Problem führt, wenn ich die Daten in der Datenbank finde und sie an den Client-Rich-Text zurückgebe Es kommt zu einem Fehler. Mein Echo-Inhalt lautet wie folgt:
<!--# include virtual="/sinclude/test.shtml" --> <!--# include virtual="/sinclude/test1.shtml" --> <!--# include virtual="/sinclude/test2.shtml" -->Auf der Seite wird dieses Formular angezeigt:
Das macht mich ein wenig deprimiert, weil andere Funktionen auf dem Server SSI verwenden müssen, aber ich brauche es hier nicht. Was soll ich tun?
Zu diesem Zeitpunkt dachte ich an ssi_types, und es gibt auch einen häufig verwendeten Text/Plain-Typ. Im Browser bleibt der gesamte Inhalt erhalten. Es wird dynamisch angezeigt, ohne dass HTML und CSS analysiert werden müssen. Wenn dieser Typ verwendet wird, wird Nginx nicht erweitert. Versuchen Sie, das MIME zu ändern, bevor Sie Folgendes ausgeben:
header('Content-type: text/plain');Tatsächlich stimmt die Ausgabe nach der Änderung des MIME mit der in der Datenbank überein und bleibt unverändert:
Es scheint, dass das Problem gelöst wurde, aber ich habe aus historischen Gründen nicht damit gerechnet, dass der Inhalt im Hintergrundbearbeitungsfeld zusammen mit anderen Inhalten zurückgegeben wird. Dies ist peinlich , der gesamte Inhalt wird in Textform im Browser angezeigt, das Problem ist immer noch nicht gelöst~~
Zu diesem Zeitpunkt denke ich an die Nginx-Konfiguration, da die Dateien, die von Nginx analysiert und erweitert werden müssen, im Allgemeinen Suffixe wie SHTML und HTML haben und die Abfragedatenbank normalerweise PHP ist, kann ich die Verwendung von SSI reduzieren zu Dateien mit den Suffixen shtml und html Schauen Sie sich die Konfiguration an. Hier werde ich die SSI-Konfigurationsinformationen in eine Übereinstimmung verschieben und mir dann den Effekt ansehen,
location ~* \.(html|shtml|htm)$ { ssi on; ssi_types text/shtml; proxy_pass http://www.testssi.com; }Erstellen Sie neue HTML- und PHP-Dateien mit ähnlichem Inhalt,
<?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!!Sie werden feststellen, dass der PHP-Zugriff nur Test!! ausgibt und andere Inhalte nur durch Anzeigen des Quellcodes in HTML angezeigt werden können. Er wird analysiert und der der enthaltenen Datei entsprechende Inhalt wird ausgegeben Fehler wird gemeldet, wenn er nicht gefunden wird! ! Zu diesem Zeitpunkt ist das Problem im Grunde genommen gelöst. Wenn Sie diese Methode nächste Woche nach der Arbeit ausprobieren, sollte es kein Problem sein.
Das Urheberrecht dieses Artikels liegt für immer beim Autor (luluyrt@163.com). Nach dem Nachdruck des Artikels muss der Autor und der Originaltext verlinkt werden an einer gut sichtbaren Stelle auf der Artikelseite angegeben werden.
Das Obige stellt die Forschung zu SSI-Problemen in Nginx vor, einschließlich ihrer Aspekte. Ich hoffe, dass es für Freunde hilfreich sein wird, die sich für PHP-Tutorials interessieren.