Por que os webapps Java usam a extensão .do? De onde veio?

Sempre me perguntei por que tantos desenvolvedores Java usam ".do" como extensão para seus recursos de controlador da web (MVC). Exemplo: http://example.com/register.do

Nem parece ser específico do framework, como vi nos projetos Spring MVC e Struts. De onde veio essa prática de extensão ".do". Por que isso foi feito em vez de nenhuma extensão? Eu sinto que perdi o memorando mundial de Java sobre isso.

Pessoalmente, prefiro nenhuma extensão.

Até onde sei, esta convenção foi divulgada pelo Struts1. O guia do usuário coloca assim:

5.4.2 Configurar o mapeamento ActionServlet

Observação: o material desta seção não é específico do Struts. A configuração de mapeamentos de servlet é definida na Especificação de Servlet Java. Esta seção descreve os meios mais comuns de configuração de um aplicativo.

Existem duas abordagens comuns para definir os URLs que serão processados ​​pelo servlet do controlador - correspondência de prefixo e correspondência de extensão. Uma entrada de mapeamento apropriada para cada abordagem será descrita abaixo.

A correspondência de prefixo significa que você deseja que todos os URLs que começam (após a parte do caminho do contexto) com um determinado valor sejam passados ​​para este servlet. Essa entrada pode ter a seguinte aparência:

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

o que significa que um URI de solicitação para corresponder ao /logoncaminho descrito anteriormente pode ter a seguinte aparência:

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

onde /myapplicationé o caminho de contexto sob o qual seu aplicativo é implantado.

O mapeamento de extensão, por outro lado, corresponde os URIs de solicitação ao servlet de ação com base no fato de que o URI termina com um período seguido por um conjunto definido de caracteres. Por exemplo, o servlet de processamento JSP é mapeado para o *.jsppadrão para que seja chamado para processar cada página JSP solicitada. Para usar a *.do extensão (que implica "fazer algo") , a entrada de mapeamento seria assim:

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

e um URI de solicitação para corresponder ao /logoncaminho descrito anteriormente pode ter a seguinte aparência:

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

AVISO - A estrutura não funcionará corretamente se você definir mais de um <servlet-mapping>elemento para o servlet do controlador.

AVISO - Se você estiver usando o novo suporte do módulo desde a versão 1.1, você deve estar ciente de que apenas o mapeamento de extensão é compatível.

E eu acho que essa convenção foi mantida (às vezes para não alterar os URLs mesmo depois de substituir o Struts1, às vezes apenas porque as pessoas estavam felizes com isso).

Era uma prática comum mapear seu servlet struts para * .do em web.xml para passar URLs para o servlet struts. Por exemplo:

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

Realmente não há razão para isso, exceto a convenção. Se você não usa nenhuma extensão, você precisa fazer alguma mágica para lidar com imagens e outros conteúdos estáticos de uma forma que não os envie para o seu sevlet. Freqüentemente, isso é feito em um balanceador de carga de um servidor web fronting.

Só uma dica de segurança!

É uma boa prática usar alguma extensão incomum para o seu controlador, desta forma os invasores precisarão gastar mais tempo para encontrar algumas informações sobre o site.

Portanto, se você alterar a extensão padrão, além de algumas poucas estáticas em sua estrutura que podem revelar sua mão, sua estrutura MVC pode ser completamente desconhecida.

Até mesmo mude a extensão para phpouaspx pode ser uma boa ideia.

Bem, de fato, isso é segurança por ofuscação, mas isso não é o oposto de boa segurança. Camadas de segurança por obscuridade em cima de um sistema já seguro pode ajudar. Existem prós e contras interessantes de segurança por ofuscação e quando ambos podem ser usados ​​na Internet.