Java Lesen Undekodiertes URL von Servlets

Question

Lassen Sie uns annehmen, dass ich String wie '= & /; # +%?' Ein Teil meiner URL zu sein, lassen Sie uns wie folgt sagen:

example.com/servletPath/someOtherPath/myString/something.html?a=b&c=d#asdf

wo myString ist die obige Zeichenfolge. Ich habe kritischen Teil codierte, so URL sieht aus wie

example.com/servletPath/someOtherPath/%3D%26%3F%2F%3B%23%2B%25/something.html?a=b&c=d#asdf

So weit, so gut.

Wenn ich im Servlet bin und ich lese alle request.getRequestURI(), request.getRequestURL() oder request.getPathInfo(), zurückgegebene Wert ist bereits dekodiert, so dass ich strilng wie

someOtherPath/=&?/;#+%/something.html?a=b&c=d#asdf

und ich kann nicht zwischen echten Sonderzeichen und codiert diejenigen unterscheiden.

Ich habe überhaupt durch das Verbot oben Zeichen besonderes Problem gelöst, das in dieser Situation funktioniert, aber ich frage mich immer noch ist es eine Möglichkeit, undekodierten URL in Servlet-Klasse zu erhalten.

YET ANOTHER EDIT: Wenn ich dieses Problem gestern Abend getroffen habe, war ich zu müde, zu bemerken, was wirklich los ist, das ist noch bizarre Ich habe Servlet abgebildet auf, sagen / servletPath ich kann / * danach setzen, was ich will und meine Servlet abhängig von dem Rest eines Weges reagieren, außer , wenn% 2F auf dem Weg ist. In diesem Fall Anfrage trifft nie das Servlet , und ich bekomme 404! Wenn i ‚/‘ statt% 2F setzen funktioniert es OK. Ich bin mit Tomcat 6.0.14 auf Java 1.6.0-04 auf Linux.

Answer 1

Es gibt einen fundamentalen Unterschied zwischen '% 2F' und '/', die beide für den Browser und dem Server.

Die HttpServletRequest Spezifikation sagt (ohne Logik, AFAICT):

• getContextPath: nicht decodiert
• getPathInfo: dekodiert
• getPathTranslated: nicht decodiert
• getQueryString: nicht decodiert
• getRequestURI: nicht decodiert
• getServletPath: dekodiert

Das Ergebnis getPathInfo () sollte decodiert werden, aber das Ergebnis von getRequestURI () muss nicht decodiert werden. Wenn ja, wird Ihre Servlet-Container brechen die Spezifikation (als Wouter Coekaerts und Francois Gravel richtig darauf hingewiesen). Welche Tomcat-Version sind Sie?

Was die Sache noch verwirrender, aktuelle Tomcat Versionen ablehnen Pfade, die Codierungen von bestimmten Sonderzeichen enthalten, aus Sicherheitsgründen .

Answer 2

Wenn es ein %2F in der entschlüsselten url, es bedeutet, dass die codiert url enthalten %252F.

Da %2F / ist Warum nicht einfach auf "\/" geteilt und nicht über die URL-Codierung sorgen?

Answer 3

Nach dem Javadoc , getRequestURI sollte die Zeichenfolge nicht entschlüsseln. Auf der anderen Seite, kehrt getServletPath eine decodierte Zeichenfolge. Getestet habe ich diese lokal mit Jetty und es verhält sich wie im doc beschrieben.

So könnte es etwas anderes im Spiel in Ihrer Situation, da das Verhalten sein Sie beschreiben in der Dokumentation Sun stimmt nicht überein.

Answer 4

Es scheint, wie Sie versuchen, etwas resty (verwenden Jersey) zu tun. Kann ist Sie analysieren off nur die führenden und Teile der URL Hinter die Daten, die Sie suchen zu bekommen?

url.substring (startLength, url.length - endLength);

Answer 5

Update: diese Antwort wurde ursprünglich falsch besagt, dass '/' und '% 2F' in einem Pfad sollte immer gleich behandelt werden. Sie sind in der Tat anders, weil ein Pfad eine Liste von / -separated Segmenten ist.

Sie sollten keinen Unterschied zwischen einem codierten und nicht codierten Zeichen in der Pfad Teil der URL zu machen. Es gibt keine Zeichen innerhalb der Bahn, die eine besondere Bedeutung in einer URL hat. Z.B. ‚% 2F‘ müssen die gleiche interpretiert werden als ‚/‘, und ein Browser, eine solche URL Zugriff ist kostenlos einen durch die andere zu ersetzen, wie es für richtig hält. Ein Unterschied zwischen ihnen bricht den Standard, wie URLs codiert werden.

In der vollständigen URL, müssen Sie einen Unterschied zwischen entkommen und nicht-Escape-Zeichen aus verschiedenen Gründen, einschließlich:

• Um zu sehen, wo der Pfad Teil endet. Weil ein ? codiert in dem Pfad soll nicht als das Ende zu sehen.
• Innerhalb des Abfrage-String. Da ein Teil des Wertes eines Parameters enthalten könnte ‚&‘ oder ‚=‘, ...
• Innerhalb eines Pfades, a '/' trennt zwei Segmente, während '% 2F' innerhalb eines Segments enthalten sein können,

Java beschäftigt sich gut mit den ersten beiden Fällen:

• getPathInfo(), die nur den Pfad Teil zurückgibt, decodiert
• getParameter(String) den Zugriff auf Teile der Abfrage Teil

Es befaßt sich nicht so gut mit dem dritten Fall. Wenn man einen Unterschied zwischen ‚/‘, wie die Trennung von zwei Pfadsegmenten machen will, und ein ‚/‘ in einem Wegsegment (% 2F), dann kann man nicht konsequent den Pfad als eine dekodierte Zeichenkette darstellen. Sie können entweder als eine codierte Zeichenfolge repräsentieren (zB „foo / bar 2Fbaz%“), oder als eine Liste von decodierten Segmente (zB „foo“, „bar / Baz“). Aber weil getPathInfo () API nur, dass (eine dekodiert string) zu tun verspricht, hat sie keine andere Wahl, als zu behandeln ‚/‘ und ‚% 2F‘ als die gleiche.

Für die gängigen Web-Anwendungen ist dies nur in Ordnung. Wenn Sie in dem seltenen Fall, wo Sie wirklich brauchen, um den Unterschied zu machen, können Sie Ihre eigenen Parsen der URL zu tun, die Rohfassung mit getRequestURI() bekommen. Wenn das eine decodiert die URL gibt, wie Sie behaupten, dann bedeutet, dass es einen Fehler in der Servlet-Implementierung ist Sie verwenden.