Perché le webapp Java utilizzano l'estensione .do? Da dove proviene?

Mi sono sempre chiesto perché così tanti sviluppatori Java utilizzano ".do" come estensione per le risorse del loro controller web (MVC). Esempio: http://example.com/register.do

Non sembra nemmeno essere specifico per il framework come l'ho visto nei progetti Spring MVC e Struts. Da dove viene questa pratica di estensione ".do". Perché è stato fatto questo invece di nessuna estensione? Mi sembra di aver perso il memo del mondo Java su questo.

Personalmente preferisco nessuna estensione.

Per quanto ne so, questa convenzione è stata diffusa da Struts1. La guida per l'utente lo mette in questo modo:

5.4.2 Configurare la mappatura ActionServlet

Nota: il materiale in questa sezione non è specifico per Struts. La configurazione dei mapping servlet è definita nella specifica Java Servlet. Questa sezione descrive i mezzi più comuni per configurare un'applicazione.

Esistono due approcci comuni per definire gli URL che verranno elaborati dal servlet del controller: corrispondenza del prefisso e corrispondenza dell'estensione. Di seguito verrà descritta una voce di mappatura appropriata per ciascun approccio.

La corrispondenza del prefisso significa che si desidera che tutti gli URL che iniziano (dopo la parte del percorso di contesto) con un valore particolare vengano passati a questo servlet. Tale voce potrebbe essere simile a questa:

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

il che significa che un URI di richiesta per abbinare il /logonpercorso descritto in precedenza potrebbe essere simile a questo:

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

dove /myapplicationè il percorso del contesto in cui viene distribuita l'applicazione.

La mappatura dell'estensione, d'altra parte, abbina gli URI della richiesta al servlet dell'azione in base al fatto che l'URI termina con un punto seguito da un insieme definito di caratteri. Ad esempio, il servlet di elaborazione JSP viene mappato al *.jsppattern in modo che venga richiamato per elaborare ogni pagina JSP richiesta. Per utilizzare l' *.do estensione (che implica "fai qualcosa") , la voce di mappatura sarebbe simile a questa:

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

e un URI di richiesta per abbinare il /logonpercorso descritto in precedenza potrebbe essere simile a questo:

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

ATTENZIONE - Il framework non funzionerà correttamente se si definiscono più <servlet-mapping>elementi per il servlet del controller.

ATTENZIONE - Se stai usando il supporto del nuovo modulo dalla versione 1.1, dovresti essere consapevole che è supportata solo la mappatura delle estensioni.

E penso che questa convenzione sia stata mantenuta (a volte per non modificare gli URL anche dopo aver sostituito Struts1, a volte solo perché le persone ne erano soddisfatte).

Era pratica comune mappare il tuo servlet struts su * .do in web.xml per passare gli URL al servlet struts. Per esempio:

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

Non c'è davvero alcun motivo tranne la convenzione per questo. Se non usi alcuna estensione, devi fare un po 'di magia per gestire le immagini e altri contenuti statici in un modo che non li invii al tuo sevlet. Spesso questo viene fatto su un bilanciamento del carico di un server web fronting.

Solo un consiglio di sicurezza!

È buona norma utilizzare qualche estensione insolita per il proprio controller, in questo modo gli intrusi avranno bisogno di dedicare più tempo per trovare alcune informazioni sul sito.

Quindi, se modifichi l'estensione predefinita, oltre ad alcune statistiche nel tuo framework che potrebbero rivelare la tua mano, il tuo framework MVC può essere completamente sconosciuto.

Anche cambiare l'estensione in phpo aspxpotrebbe essere una buona idea.

In effetti questa è sicurezza mediante offuscamento, ma non è l'opposto di una buona sicurezza. Potrebbe essere utile stratificare la sicurezza per oscurità su un sistema già protetto. Ci sono vantaggi e svantaggi interessanti della sicurezza tramite offuscamento e quando possono essere utilizzati entrambi in Internet.