Detaillierte Erläuterung des Problems bei der Konfiguration des Servlet-URL-Musters in Tomcat

Beim Konfigurieren von web.xml für Tomcat ist Servlet ein relativ wichtiges Thema. Hier diskutieren wir mehrere Schwachstellen bei Servlets.

1. Problem beim Abgleichen von Servlet-URL-Mustern
2. Der Unterschied zwischen / und /* im URL-Muster
3. Prioritätsausgabe des URL-Musters
4. Stammpfad / Übereinstimmungsproblem

1 Problem beim Abgleichen von Servlet url-pattern

Es gibt drei Übereinstimmungsmodi für url-pattern : Pfadübereinstimmung, exakte Übereinstimmung und Suffixübereinstimmung.

1.1 Genaue Übereinstimmung

Die im <url-pattern> konfigurierten Elemente müssen exakt mit der URL übereinstimmen.

Codebeispiel: point_down:

<Servlet-Zuordnung>
 <servlet-name>MeinServlet</servlet-name>
 <URL-Muster>/kata/detail.html</URL-Muster>
 <URL-Muster>/demo.html</URL-Muster>
 <URL-Muster>/Tabelle</URL-Muster>
</servlet-mapping>

Wenn Sie die folgenden URLs im Browser eingeben, werden sie dem Servlet zugeordnet

http://10.43.11.143/myapp/kata/detail.html
http://10.43.11.143/myapp/demo.html

http://10.43.11.143/myapp/table

Beachten:

http://10.43.11.143/myapp/table/ ist eine ungültige URL und wird nicht als http://10.43.11.143/myapp/table erkannt.

Darüber hinaus können auf die obige URL beliebige Abfragebedingungen folgen, die dann abgeglichen werden, wie zum Beispiel

Die Anfrage http://10.43.11.143/myapp/table?hello wird mit MyServlet abgeglichen.

1.2 Pfadanpassung

Für die Pfadübereinstimmung wird eine Zeichenfolge verwendet, die mit dem Zeichen „/“ beginnt und mit „/*“ endet.

Codebeispiel: point_down:

<Servlet-Zuordnung>
 <servlet-name>MeinServlet</servlet-name>
 <URL-Muster>*.jsp</URL-Muster>
 <URL-Muster>*.Aktion</URL-Muster>
</servlet-mapping>

Der Pfad beginnt mit /user/ und der Rest des Pfades kann beliebig sein. Beispielsweise werden die folgenden URLs abgeglichen.

http://localhost:8080/appDemo/user/users.html

http://localhost:8080/appDemo/user/addUser.action

http://localhost:8080/appDemo/user/updateUser.actionl

1.3 Suffix-Matching

Zeichenfolgen, die mit „*.“ beginnen, werden für die Suffixübereinstimmung verwendet.

Codebeispiel: point_down:

<Servlet-Zuordnung>
 <servlet-name>MeinServlet</servlet-name>
 <URL-Muster>*.jsp</URL-Muster>
 <URL-Muster>*.Aktion</URL-Muster>
</servlet-mapping>

Dann wird jede URL-Anfrage mit der Erweiterung jsp oder action abgeglichen, beispielsweise werden die folgenden URLs abgeglichen

http://localhost:8080/appDemo/user/users.jsp

http://localhost:8080/appDemo/toHome.action

Hinweis: Pfad- und Suffixübereinstimmung können nicht gleichzeitig festgelegt werden

Hinweis: Pfad- und Erweiterungsübereinstimmung können nicht gleichzeitig festgelegt werden, wie beispielsweise die folgenden drei Sie sind alle unzulässig. Wenn sie gesetzt sind, wird beim Starten des Tomcat-Servers ein Fehler gemeldet.

<url-pattern>/kata/*.jsp</url-pattern>

<url-pattern>/*.jsp</url-pattern>

<url-pattern>he*.jsp</url-pattern>

Einige Beispiele: point_down:, wenn Sie es nicht verstehen, lesen Sie bitte Kapitel 3 dieses Artikels

2 Der Unterschied zwischen / und /* im URL-Muster

<url-pattern>/</url-pattern>

<url-pattern>/*</url-pattern>

Lassen Sie uns zuerst über /* sprechen. /* ist relativ einfach zu verstehen. Es ist eine Art von Pfadübereinstimmung. In Bezug auf den Umfang ist es die umfassendste Pfadübereinstimmung, und alle Anforderungen erfüllen seine Anforderungen. In Bezug auf die Genauigkeit ist es die Pfadübereinstimmung mit der geringsten Genauigkeit ( Hinweis: Ich spreche von Pfadübereinstimmung ). Die Priorität der Pfadübereinstimmung reicht von lang nach kurz ( Einzelheiten finden Sie in Kapitel 3 dieses Artikels ), daher ist es die Pfadübereinstimmung mit der geringsten Genauigkeit. In vielen Blogs heißt es, dass die Funktion darin besteht, *.jsp abzugleichen. Ist das nicht Unsinn? /* selbst ist ein Pfadmatcher, daher kann es sicherlich mit *.jsp übereinstimmen.

Außerdem hat / die niedrigste Priorität . Wenn eine URL nicht / allen url-pattern übereinstimmt, wird die URL zur Übereinstimmung an / weitergeleitet. Es gibt überhaupt keine *.jsp Einschränkung. Der Grund, warum jeder denkt (und objektiv gesehen stimmt das), dass / nicht mit *.jsp übereinstimmt, aber /* mit *.jsp übereinstimmt, ist, dass *.jsp separat in tomcat/conf/web.xml konfiguriert wird. Weitere Einzelheiten finden Sie in Kapitel 3 dieses Artikels .

3 Probleme mit der Priorität von URL-Mustern

Wenn eine URL den Übereinstimmungsregeln mehrerer Servlets entspricht, wird das entsprechende Servlet entsprechend der Priorität „genauer Pfad > längster Pfad > Suffix-Übereinstimmung“ abgeglichen.

Beispiel 1: Beispielsweise ist das URL-Muster von ServletA /test und das URL-Muster von ServletB /*. Wenn die von mir besuchte URL zu diesem Zeitpunkt http://localhost/test ist, führt der Container zuerst eine exakte Pfadübereinstimmung durch und stellt fest, dass /test exakt mit ServletA übereinstimmt. In diesem Fall wird ServletA aufgerufen, ohne sich um ServletB zu kümmern.

Beispiel 2: Wenn beispielsweise das URL-Muster von ServletA /test/ und das URL-Muster von ServletB /test/a/ ist , wählt der Container beim Zugriff auf http://localhost/test/a das Servlet mit dem längsten passenden Pfad aus, in diesem Fall also ServletB.

Beispiel 3: Beispielsweise lautet das URL-Muster von ServletA: *.action und das URL-Muster von ServletB ist / * . Wenn die von mir besuchte URL zu diesem Zeitpunkt http://localhost/test.action lautet, gibt der Container der Pfadübereinstimmung Vorrang vor der Übereinstimmung mit der Erweiterung, um ServletB aufzurufen.

Dann stellt sich eine Frage. Warum stimmt /* mit *.jsp überein, aber / nicht mit *.jsp ?

Der Grund ist ganz einfach. In tomcat/conf/web.xml gibt es folgende Konfiguration

<Servlet-Zuordnung>
 <Servlet-Name>Standard</Servlet-Name>
 <URL-Muster>/</URL-Muster>
</servlet-mapping>

<!-- Die Zuordnungen für das JSP-Servlet -->
<Servlet-Zuordnung>
 <Servlet-Name>jsp</Servlet-Name>
 <URL-Muster>*.jsp</URL-Muster>
 <URL-Muster>*.jspx</URL-Muster>
</servlet-mapping>

:point_up_2: Es ist deutlich zu erkennen, dass *.jsp die Suffixübereinstimmung für das Servlet mit dem Namen jsp ist und /* die Pfadübereinstimmung, die eine höhere Priorität als die Suffixübereinstimmung hat, sodass sie mit der Datei mit dem Suffix jsp übereinstimmen kann. Da / jedoch die Übereinstimmung auf der niedrigsten Ebene ist und unter der Suffixübereinstimmung liegt, wird die JSP-Datei nicht mit url-pattern von / abgeglichen.

4 Root-Pfad / Matching-Problem

Möglicherweise ist Ihnen ein Problem aufgefallen: Wenn das URL-Muster /* ist, führt der Zugriff auf http://localhost:8080/ zu einer 404-Fehlermeldung, der Zugriff auf http://localhost:8080/index.html funktioniert jedoch einwandfrei (Voraussetzung ist natürlich, dass <mvc:default-servlet-handler/> im Spring-Container konfiguriert ist). Wenn das URL-Muster / ist, wird http://localhost:8080/ automatisch ohne 404 an http://localhost:8080/index.html weitergeleitet. Was ist der Grund?

Zunächst muss geklärt werden, was das Stammverzeichnis einer URL, also / (z. B. http://localhost:8080/), bedeutet? Durch Experimente haben wir festgestellt, dass / etwas ganz Besonderes ist. Es wird mit dem URL-Muster von /* abgeglichen, aber nicht mit dem URL-Muster von /.

In Tomcat wird / standardmäßig von defaultservlet abgeglichen, aber seine Priorität ist niedriger als die Pfadabgleichung. Wenn also das URL-Muster eines Servlets /* ist, wird / von diesem Servlet abgeglichen und nicht von defaultservlet.

Der folgende im Tomcat-Quellcode gefundene Ausschnitt kann meine Ansicht unterstützen: point_down:

<!-- ====================== Standard-Willkommensdateiliste ====================== -->
<!-- Wenn eine Anforderungs-URI auf ein Verzeichnis verweist, sieht das Standard-Servlet aus -->
<!-- für eine „Willkommensdatei“ in diesem Verzeichnis und, falls vorhanden, für die -->
<!-- entsprechende Ressourcen-URI zur Anzeige. -->
<!-- Wenn keine Willkommensdateien vorhanden sind, stellt das Standard-Servlet entweder ein --> bereit.
<!-- Verzeichnisliste (siehe Standard-Servlet-Konfiguration für weitere Informationen -->
<!-- anpassen) oder gibt einen 404-Status zurück, abhängig vom Wert des -->
<!-- Auflistungseinstellung. -->
<!-- -->
<!-- Wenn Sie Willkommensdateien in der web.xml Ihrer eigenen Anwendung definieren -->
<!-- Bereitstellungsdeskriptor, diese Liste *ersetzt* die konfigurierte Liste -->
<!-- hier, also achten Sie darauf, alle gewünschten Standardwerte einzuschließen -->
<!-- zur Verwendung in Ihrer Anwendung.

:point_up_2:Das Obige bezieht sich auf Welcome File List , d. h. der / Pfad wird standardmäßig an die in Welcome File List angegebene Webseite weitergeleitet, d. h. an die Startseite. Ich werde einen Teil des obigen Textes übersetzen. Für weitere Einzelheiten können Sie Google Translate verwenden. Übersetzung: point_right:

Übersetzung:point_down:

Wenn die Anforderungs-URI auf ein Verzeichnis verweist, sucht das Standard-Servlet in diesem Verzeichnis und, falls vorhanden, in der entsprechenden Ressourcen-URI nach einer „Willkommensdatei“ zur Anzeige. Wenn keine Willkommensdatei vorhanden ist, stellt das Standard-Servlet entweder eine Verzeichnisliste bereit (Informationen zur Anpassung finden Sie in der Standard-Servlet-Konfiguration) oder gibt einen 404-Status zurück, abhängig vom Wert der Listeneinstellung.

Der Grund, warum / auf die Willkommensseite umgeleitet wird, ist das Vorhandensein von Welcome File List . Die Voraussetzung für die Funktion Welcome File List ist, dass / mit defaultservlet abgeglichen werden muss. Wenn das URL-Muster eines Servlets /* ist, wird / von diesem Servlet abgeglichen und nicht vom Standardservlet. Nur wenn das URL-Muster des selbst definierten Servlets / ist, wird http://localhost:8080/ automatisch an http://localhost:8080/index.html weitergeleitet, ohne dass eine 404-Fehlermeldung auftritt.

Zusammenfassen

Dies ist das Ende dieses Artikels mit der detaillierten Erklärung des Problems der Konfiguration des Servlet-URL-Musters in Tomcat. Weitere relevante Inhalte zur Tomcat-Konfiguration des Servlets finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder durchsuchen Sie die verwandten Artikel weiter unten. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!