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

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.

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

où /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).

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.

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.