ejemplos - taglib java

¿Por qué Java webapps usa la extensión.do? ¿De dónde vino?

Question

Siempre me he preguntado por qué tantos desarrolladores de Java usan ".do" como la extensión para sus recursos de controlador web (MVC). Ejemplo: http://example.com/register.do

Ni siquiera parece ser específico del framework como lo he visto en los proyectos Spring MVC y Struts. ¿De dónde vino esta práctica de extensión ".do"? ¿Por qué se hizo esto en lugar de sin extensión? Siento que me perdí el memorando mundial de Java sobre esto.

Personalmente prefiero ninguna extensión.

Answer 1

¡Solo un consejo de seguridad!

Es una buena práctica usar alguna extensión inusual para su controlador, de esta forma los intrusos necesitarán pasar más tiempo para encontrar información sobre el sitio.

Por lo tanto, si cambia la extensión predeterminada, además de algunas pocas estáticas en su marco que pueden revelar su mano, su marco MVC puede ser completamente desconocido.

Incluso cambiar la extensión a php o aspx podría ser una buena idea.

Bueno, en verdad esto es seguridad por ofuscación, pero esto no es lo opuesto a una buena seguridad. La seguridad en capas por oscuridad sobre un sistema ya seguro podría ayudar. Existen pros y contras interesantes de seguridad por ofuscación y cuando ambos se pueden usar en Internet.

Answer 2

Era una práctica común asignar su servlet de struts a * .do en web.xml para pasar las URL al servlet de struts. Por ejemplo:

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

Realmente no hay ninguna razón excepto la convención para esto. Si no usas ninguna extensión, necesitas hacer algo de magia para manejar las imágenes y otro contenido estático de una manera que no los tenga en tu sevlet. A menudo, esto se realiza en un equilibrador de carga del servidor web frontal.

Answer 3

Que yo sepa, esta convención ha sido difundida por Struts1. La guía del usuario lo dice así:

5.4.2 Configurar la asignación de ActionServlet

Nota: El material en esta sección no es específico de Struts. La configuración de las asignaciones de servlets se define en la Especificación del Servlet de Java. Esta sección describe los medios más comunes para configurar una aplicación.

Hay dos enfoques comunes para definir las URL que serán procesadas por el servlet del controlador: coincidencia de prefijo y concordancia de extensión. A continuación, se describirá una entrada de mapeo apropiada para cada enfoque.

La coincidencia de prefijo significa que desea que todas las URL que se inician (después de la parte de la ruta de contexto) con un valor particular pasen a este servlet. Tal entrada podría verse así:

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

lo que significa que un URI de solicitud para que coincida con la ruta /logon descrita anteriormente podría tener este aspecto:

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

donde /myapplication es la ruta de contexto bajo la cual se implementa su aplicación.

El mapeo de extensiones, por otro lado, coincide con los URI de solicitud para el servlet de acción en función del hecho de que el URI finaliza con un período seguido de un conjunto definido de caracteres. Por ejemplo, el servlet de procesamiento JSP se asigna al patrón *.jsp para que se llame a procesar cada página JSP que se solicite. Para usar la extensión *.do (que implica "hacer algo") , la entrada de asignación se vería así:

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

y un URI de solicitud para que coincida con la ruta /logon descrito anteriormente podría tener este aspecto:

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

ADVERTENCIA : el marco no funcionará correctamente si define más de un elemento <servlet-mapping> para el servlet del controlador.

ADVERTENCIA : si está utilizando el nuevo soporte del módulo desde la versión 1.1, debe tener en cuenta que solo se admite el mapeo de extensiones.

Y creo que esta convención se ha mantenido (a veces para no cambiar las URL incluso después de reemplazar Struts1, a veces simplemente porque la gente estaba contenta con eso).