Pourquoi les applications Web Java utilisent-elles l'extension .do? D'où vient-il?


114

Je me suis toujours demandé pourquoi tant de développeurs Java utilisent ".do" comme extension pour leurs ressources de contrôleur Web (MVC). Exemple: http://example.com/register.do

Cela ne semble même pas être spécifique au framework, comme je l'ai vu dans les projets Spring MVC et Struts. D'où vient cette pratique d'extension ".do". Pourquoi cela a-t-il été fait au lieu d'aucune extension? J'ai l'impression d'avoir manqué le mémo mondial de Java à ce sujet.

Personnellement, je ne préfère aucune extension.


4
Note conviviale pour les personnes qui souhaitent migrer depuis ".do" et ont des URL conviviales. Utilisez le chemin du servlet au lieu de l'extension ie / do / login, puis utilisez la réécriture d'URL du filtre Tuckey pour faire / do / login ==> / login.
Adam Gent

Certes, la réécriture d'URL (que ce soit via mod_rewrite ou le filtre de Tuckey) ferait l'affaire.
Pascal Thivent

1
c'est assez idiot, et il n'y a aucune excuse pour cela.
irréprochable

Réponses:


75

A ma connaissance, cette convention a été diffusée par Struts1. Le guide de l'utilisateur l'exprime comme ceci:

5.4.2 Configurer le mappage ActionServlet

Remarque: le contenu de cette section n'est pas spécifique aux entretoises. La configuration des mappages de servlet est définie dans la spécification de servlet Java. Cette section décrit les moyens les plus courants de configuration d'une application.

Il existe deux approches courantes pour définir les URL qui seront traitées par le servlet du contrôleur: la correspondance de préfixe et la correspondance d'extension. Une entrée de mappage appropriée pour chaque approche sera décrite ci-dessous.

La correspondance de préfixe signifie que vous voulez que toutes les URL qui commencent (après la partie du chemin de contexte) avec une valeur particulière soient transmises à ce servlet. Une telle entrée pourrait ressembler à ceci:

<servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>/do/*</url-pattern>
</servlet-mapping>

ce qui signifie qu'une URI de demande pour correspondre au /logonchemin décrit précédemment pourrait ressembler à ceci:

http://www.mycompany.com/myapplication/do/logon

/myapplicationest le chemin du contexte sous lequel votre application est déployée.

Le mappage d'extension, d'autre part, fait correspondre les URI de demande au servlet d'action sur la base du fait que l'URI se termine par un point suivi d'un ensemble défini de caractères. Par exemple, le servlet de traitement JSP est mappé au *.jspmodèle afin qu'il soit appelé pour traiter chaque page JSP demandée. Pour utiliser l' *.do extension (qui implique "faire quelque chose") , l'entrée de mappage ressemblerait à ceci:

<servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

et un URI de demande pour correspondre au /logonchemin décrit précédemment pourrait ressembler à ceci:

http://www.mycompany.com/myapplication/logon.do

AVERTISSEMENT - La structure ne fonctionnera pas correctement si vous définissez plus d'un <servlet-mapping>élément pour le servlet du contrôleur.

AVERTISSEMENT - Si vous utilisez le nouveau support de module depuis la version 1.1, sachez que seul le mappage d'extension est pris en charge.

Et je pense que cette convention a été conservée (parfois pour ne pas changer les URL même après avoir remplacé Struts1, parfois simplement parce que les gens en étaient satisfaits).


2
J'ai pensé que c'était Struts 1. Il y a si longtemps, j'ai dû oublier. Ce n'étaient pas les bons jours pour Java Web Dev.
Adam Gent

4
@Adam À cette époque (~ 2001), j'étais satisfait de Struts1. Aujourd'hui, l'utiliser me ferait pleurer.
Pascal Thivent

5
En 2001, nous avons eu la chance d'avoir Struts 1!
Thorbjørn Ravn Andersen

2
Avec Struts 2, nous pouvons tous être heureux!
Alireza Fattahi

9

Il était courant de mapper votre servlet struts à * .do dans web.xml pour transmettre des URL au servlet struts. Par exemple:

<!-- Standard Action Servlet Mapping -->
<servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

Il n'y a vraiment aucune raison sauf convention pour cela. Si vous n'utilisez aucune extension, vous devez faire de la magie pour gérer les images et autres contenus statiques d'une manière qui ne les envoie pas à votre sevlet. Cela se fait souvent au niveau d'un équilibreur de charge d'un serveur Web frontal.


2
Je ne sais pas si c'est magique. Tout ce qu'il faut, c'est avoir un servlet de répartition principal et peut-être faire une réécriture d'URL pour éviter d'avoir le préfixe / myservlet /. Voir Réécriture d'URL Tuckey.
Adam Gent

-2

Juste un conseil de sécurité!

Il est recommandé d'utiliser une extension inhabituelle pour votre contrôleur, de cette manière les intrus devront passer plus de temps pour trouver des informations sur le site.

Donc, si vous changez l'extension par défaut, ainsi que quelques statiques dans votre framework qui peuvent révéler votre main, votre framework MVC peut être complètement inconnu.

Même changer l'extension phpou aspxpourrait être une bonne idée.

Eh bien, en effet, c'est la sécurité par obfuscation, mais ce n'est pas le contraire d'une bonne sécurité. Superposer la sécurité par l'obscurité sur un système déjà sécurisé pourrait aider. Il y a des avantages et des inconvénients intéressants de la sécurité par obfuscation et quand ils peuvent être tous deux utilisés sur Internet.


5
C'est la sécurité par l'obscurité.
TGO

Vraiment c'est obfuscation
Brandon G

4
L'obscurité n'est pas le contraire d'une bonne sécurité. Refuser de divulguer des informations dont les clients n'ont aucun besoin de savoir est une bonne pratique. Dans mon entreprise, nous avons nettoyé tous les en-têtes de serveurs Web et d'applications et les avons remplacés par une chaîne inventée. Le nombre d'analyses de vulnérabilités, même les sites obscurs, est fou, tout ce que vous pouvez faire pour vous rendre moins cible est un avantage.
XP84

Par défaut, les en-têtes de réponse suffiraient à comprendre les choses.
Kannan Ramamoorthy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.