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


114

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.


4
Nota amigável para pessoas que desejam migrar de ".do" e têm URLs amigáveis. Use o caminho do servlet em vez da extensão, ou seja, / do / login e, em seguida, use a reescrita do URL do Filtro Tuckey para fazer / do / login ==> / login.
Adam Gent

É verdade que a reescrita de URL (seja por meio do mod_rewrite ou do filtro de Tuckey) resolveria o problema.
Pascal Thivent

1
é muito idiota e não há desculpa para isso.
irreputável de

Respostas:


75

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).


2
Achei que fosse Struts 1. Há muito tempo devo ter esquecido. Aqueles foram os dias não tão bons para Java Web Dev.
Adam Gent

4
@Adam Naquela época (~ 2001), eu estava feliz com o Struts1. Hoje, usá-lo me faria chorar.
Pascal Thivent

5
Em 2001, tivemos a SORTE de ter o Struts 1!
Thorbjørn Ravn Andersen

2
Com o Struts 2, podemos todos ser felizes!
Alireza Fattahi de

9

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.


2
Eu não sei se isso é mágico. Tudo isso é ter um servlet de despacho mestre e talvez fazer alguma reescrita de URL para evitar o prefixo / myservlet /. Consulte reescrita de URL de Tuckey.
Adam Gent

-2

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.


5
Isso é segurança por obscuridade.
TGO de

Realmente, isso é ofuscação
Brandon G

4
A obscuridade não é o oposto de uma boa segurança. Recusar-se a divulgar informações que os clientes não precisam saber é uma boa prática. Na minha empresa, removemos todos os cabeçalhos do servidor da web e do servidor de aplicativos e os substituímos por uma string feita. A quantidade de varreduras de vulnerabilidade que até mesmo sites obscuros conseguem é louca, qualquer coisa que você possa fazer para se tornar menos alvo é positivo.
XP84

Por padrão, os cabeçalhos de resposta seriam suficientes para descobrir as coisas.
Kannan Ramamoorthy
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.