Java Webアプリケーションが.do拡張子を使用するのはなぜですか？それはどこから来たのか？

なぜこれほど多くのJava開発者がWebコントローラー（MVC）リソースの拡張子として「.do」を使用するのか、いつも疑問に思っていました。例：http : //example.com/register.do

Spring MVCおよびStrutsプロジェクトで見たように、それはフレームワーク固有であるようにも見えません。この「.do」拡張子の練習はどこから来たのですか。なぜこれが拡張子なしではなく行われたのですか？これに関するJavaの世界メモを見逃したような気がします。

個人的に私は延長を好まない。

私の知る限りでは、この慣習はStruts1によって広められました。ユーザーガイドは次のように書いています：

5.4.2 ActionServletマッピングの構成

注： このセクションの内容はStrutsに固有のものではありません。サーブレットマッピングの構成は、Javaサーブレット仕様で定義されています。このセクションでは、アプリケーションを構成する最も一般的な方法について説明します。

コントローラーサーブレットによって処理されるURLを定義するには、プレフィックスマッチングと拡張子マッチングの2つの一般的なアプローチがあります。各アプローチの適切なマッピングエントリについては、以下で説明します。

プレフィックス一致とは、特定の値で始まる（コンテキストパス部分の後に続く）すべてのURLをこのサーブレットに渡すことを意味します。このようなエントリは次のようになります。

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

つまり、/logon前述のパスと一致するリクエストURIは次のようになります。

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

どこ/myapplicationアプリケーションがデプロイされるの下にコンテキストパスです。

一方、拡張マッピングは、URIがピリオドで終わり、その後に定義された文字セットが続くという事実に基づいて、リクエストURIをアクションサーブレットと照合します。たとえば、JSP処理サーブレットは*.jspパターンにマップされ、リクエストされたすべてのJSPページを処理するために呼び出されます。 拡張機能（「何かを行う」ことを意味します）を使用するには*.do、マッピングエントリは次のようになります。

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

/logon前述のパスと一致するリクエストURIは次の ようになります。

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

警告 - <servlet-mapping>コントローラサーブレットに複数の要素を定義すると、フレームワークは正しく動作しません。

警告 -バージョン1.1以降の新しいモジュールサポートを使用している場合は、拡張マッピングのみがサポートされていることに注意してください。

そして、この慣習は守られていると思います（Struts1を置き換えた後でもURLを変更しないこともあります）。

StrutsサーブレットにURLを渡すために、strutsサーブレットをweb.xmlの* .doにマップするのが一般的な方法でした。例えば：

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

慣習以外に理由はありません。拡張機能を使用しない場合、画像やその他の静的コンテンツをsevletに送信しない方法で処理するために、何らかの魔法をかける必要があります。多くの場合、これはフロントWebサーバーのロードバランサーで行われます。

セキュリティのヒントだけです！

コントローラーに通常とは異なる拡張機能を使用することをお勧めします。このようにして、侵入者はサイトに関する情報を見つけるためにより多くの時間を費やす必要があります。

したがって、デフォルトの拡張機能と、フレームワークのいくつかの静的要素を変更すると、MVCフレームワークが完全に不明になる可能性があります。

でもに拡張子を変更しphpたりaspx、良いアイデアかもしれません。

確かに、これは難読化によるセキュリティですが、これは優れたセキュリティの反対ではありません。すでに安全なシステムの上に、あいまいなセキュリティを重ねることが役立つかもしれません。難読化によるセキュリティの興味深い長所と短所があり、いつインターネットで使用できるかについて説明します。