Java de Lecture non décodé URL de la Servlet

Nous allons présumer que j'ai des chaines de caractères comme '=&?/;#+%' une partie de mon URL, disons le comme ceci:

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

où myString est au-dessus de la chaîne. J'ai encodé partie essentielle si l'URL ressemble à

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

So far So good.

Quand je suis dans la servlet et j'ai lu tout de request.getRequestURI(), request.getRequestURL() ou request.getPathInfo(), la valeur de retour est déjà décodé, alors je me strilng comme

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

et je ne peux pas la différence entre les vraies caractères spéciaux et codé.

J'ai résolu de problème particulier en interdisant au-dessus de caractères au total, qui travaille dans cette situation, mais je me demande encore est-il possible d'obtenir non décodé de l'URL dans la classe de servlet.

ENCORE un AUTRE EDIT: Quand j'ai atteint ce problème hier soir, j'étais trop fatigué pour remarquer ce qui se passe réellement, ce qui est encore plus bizarre! J'ai servlet mappé sur, disons /servletPath/* une fois que je peux mettre ce que je veux obtenir mon servlet de répondre en fonction sur le reste du chemin, sauf quand il y a %2F dans le chemin d'accès. Dans ce cas demande ne fait jamais les servlet, et je reçois 404! Si j'ai mis " /" au lieu de %2F cela fonctionne bien. Je suis en cours d'exécution de Tomcat 6.0.14 Java-1.6.0-04 sur Linux.

si la chaîne est déjà décodé, pourquoi l'aurait-il un %2f?
Quelle est la valeur retournée et que voulez-vous qu'il soit? Et est-il pertinent? Je ne peux pas vraiment dire quel est le problème.
Je n'ai pas l'obtenir.
Sonne comme le cas d'essayer de décoder de façon illégale et URL mal formée. L'exécution en dehors de la spécification de ce genre est susceptible de causer un tas de problèmes. Pouvez-vous avoir le contrôle pour changer la façon dont les données sont transmises? par exemple déplacer pour publier des données?
Pour toute personne tombant sur ce à une date ultérieure, le problème de la %2F est due à un CGI précaution de sécurité.

OriginalL'auteur Slartibartfast | 2009-06-08

  1. 21

    Il existe une différence fondamentale entre "%2F' et '/', à la fois pour le navigateur et le serveur.

    Le HttpServletRequest spécification indique (sans aucune logique, AFAICT):

    • getContextPath: pas décodé
    • getPathInfo: décodé
    • getPathTranslated: pas décodé
    • getQueryString: pas décodé
    • getRequestURI: pas décodé
    • getServletPath: décodé

    Le résultat de getPathInfo() devrait être décodé, mais le résultat de getRequestURI() ne doit pas être décodé. Si c'est votre conteneur de Servlet est de briser la spec (comme Wouter Coekaerts et François Gravier a souligné à juste titre). Qui de version de Tomcat êtes-vous en cours d'exécution?

    Rendre les choses encore plus confuses, actuel Tomcat versions rejeter les chemins qui contiennent des codages de certains caractères spéciaux, pour des raisons de sécurité.

    - getRequestURL: décodé
    Bonne table de toutes les méthodes est ici: stackoverflow.com/a/21046620/972676

    OriginalL'auteur jcsahnwaldt

  2. 2

    Si il y a un %2F dans le décodé url, cela signifie que le codé url contenue %252F.

    Depuis %2F est / Pourquoi ne pas se diviser sur "\/" et vous inquiétez pas à propos de l'encodage de l'URL?

    OriginalL'auteur Powerlord

  3. 1

    Selon la Javadoc, getRequestURI ne devrait pas décoder la chaîne. D'autre part, getServletPath retourner une chaîne décodée. J'ai testé cette localement à l'aide de la Jetée et il se comporte comme décrit dans la doc.

    Alors il pourrait y avoir quelque chose d'autre à jouer dans votre situation étant donné que le comportement que vous décrivez ne correspond pas à la documentation de Sun.

    Vous êtes en partie droite. Quand j'ai des caractères UTF-8, il reste non décodé, mais spetial caractères arent. Je suis en train de travailler sur Tomcat.

    OriginalL'auteur Francois Gravel

  4. 0

    Il semble que vous essayez de faire quelque chose de RESTy (utiliser Jersey). Pouvez vous juste parse hors de l'attaque et de fuite des parties de l'URL pour obtenir les données que vous recherchez?

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

    nope, j'ai param1/param2/param3 et ils sont tous de longueur inconnue.

    OriginalL'auteur stevedbrown

  5. -1

    Mise à jour: cette réponse a été à l'origine, à tort, en précisant que " /" et "%2F " dans un chemin d'accès doit toujours être traités de la même façon. Ils sont différents parce qu'un chemin est une liste de /-segments séparés.

    Vous ne devriez pas avoir à faire la différence entre un codées et non codées à caractère le chemin de la partie de l'URL. Il n'y a aucun caractère à l'intérieur du chemin qui peut avoir une signification particulière dans une URL. E. g. '%2F " doit être interprétée de la même chose que '/', et un navigateur accéder à cette URL est libre de remplacer l'un par l'autre comme il l'entend. Faire une différence entre eux est la rupture de la norme de la façon dont les Url sont codées.

    Dans l'URL complète, vous devez faire une différence entre les échappés et non des caractères d'échappement pour différentes raisons, y compris:

    • Pour voir où le chemin de la partie se termine. Parce qu'un ? codé dans le chemin d'accès ne doit pas être vu comme de la fin.
    • À l'intérieur de la Chaîne de requête. Parce qu'une partie de la valeur d'un paramètre peut contenir '&' ou '=',...
    • À l'intérieur d'un chemin, un " /"sépare les deux segments tandis que" %2F " peut être contenu dans un segment de

    Java traite très bien avec les deux premiers cas:

    • getPathInfo() qui renvoie uniquement le chemin d'accès de la partie, décodé
    • getParameter(String) pour accéder à des parties de la requête de la partie

    Il ne s'agit pas tellement bien avec le troisième cas. Si vous voulez faire une différence entre " /"comme la séparation des deux segments du chemin, et un" /" à l'intérieur d'un segment de chemin (%2F), alors vous ne pouvez pas systématiquement représenter le chemin d'accès comme l'un décodé chaîne. Vous pouvez soit la représenter comme une chaîne codée (par exemple, "foo/bar%2Fbaz"), ou d'une liste de segments sont ensuite (par exemple, "foo", "bar/baz").
    Mais parce que getPathInfo() de l'API promet de le faire (un décodé chaîne), il n'a pas le choix mais pour traiter de " /" et "%2F", comme le même.

    Pour habitude d'applications web, c'est tout simplement parfait. Si vous êtes dans les rares cas où vous avez vraiment besoin pour faire la différence, vous pouvez faire votre propre analyse de l'URL, l'obtention de la première version avec getRequestURI(). Si on donne l'URL décodé comme vous le prétendez, alors cela signifie qu'il ya un bug dans la servlet application que vous utilisez.

    Donc, c'était mon mauvais que j'ai pensé qu'il y est de différence entre / et %2F, alors qu'en standard, il n'y en a pas. Comme je l'ai dit, j'ai ignorer le problème en éliminant les caractères avant de toucher l'encodage de l'url de la partie, ce qui est je suppose que la norme compilant.
    En fait, je crois qu'il y a une différence entre "/" et "%2F" dans le chemin. RFC3986 indique que le chemin est "/"séparée de la séquence de "segments du chemin". Donc, si vous voulez un "segment de chemin" contenant une barre oblique, il doit être encodé en %2F. C'est ce que dit par exemple dans l'article de Wikipédia sur le pourcentage de codage. Ma compréhension, c'est bien d'avoir un serveur qui utilise cette distinction, et un navigateur qui n'a pas de maintenir la distinction serait brisé.
    Vous avez raison. J'ai juste modifié la réponse pour résoudre ce problème.

    OriginalL'auteur Wouter Coekaerts