Почему веб-приложения Java используют расширение .do? Откуда это?

Я всегда задавался вопросом, почему так много разработчиков Java используют ".do" в качестве расширения для своих ресурсов веб-контроллера (MVC). Пример: http://example.com/register.do

Он даже не кажется специфичным для фреймворка, как я видел это в проектах Spring MVC и Struts. Откуда взялась эта практика расширения ".do". Почему это было сделано вместо того, чтобы не продлевать? Я чувствую, что пропустил меморандум о мире Java по этому поводу.

Лично я не предпочитаю продления.

Насколько мне известно, это соглашение было распространено Struts1. В руководстве пользователя это написано так:

5.4.2 Настройка сопоставления ActionServlet

Примечание . Материал в этом разделе не относится к Struts. Конфигурация сопоставлений сервлетов определена в Спецификации сервлетов Java. В этом разделе описаны наиболее распространенные способы настройки приложения.

Существует два общих подхода к определению URL-адресов, которые будут обрабатываться сервлетом контроллера: сопоставление префиксов и сопоставление расширений. Соответствующая запись отображения для каждого подхода будет описана ниже.

Сопоставление префиксов означает, что вы хотите, чтобы все URL-адреса, которые начинаются (после части пути контекста) с определенного значения, передавались этому сервлету. Такая запись может выглядеть так:

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

Это означает, что URI запроса, соответствующий /logonописанному ранее пути, может выглядеть так:

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>

а URI запроса, соответствующий /logonописанному ранее пути, может выглядеть так:

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

ВНИМАНИЕ! Платформа не будет работать правильно, если вы определите более одного <servlet-mapping>элемента для сервлета контроллера.

ПРЕДУПРЕЖДЕНИЕ. Если вы используете поддержку нового модуля, начиная с версии 1.1, вы должны знать, что поддерживается только сопоставление расширений.

И я думаю, что это соглашение было соблюдено (иногда для того, чтобы не менять URL-адреса даже после замены Struts1, иногда просто потому, что людям это понравилось).

Обычной практикой было сопоставление сервлета struts с * .do в web.xml для передачи URL-адресов сервлету struts. Например:

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

На самом деле для этого нет никаких оснований, кроме условностей. Если вы не используете расширение, вам нужно сделать некоторую магию для обработки изображений и другого статического контента таким образом, чтобы они не отправлялись в ваш севлет. Часто это делается на балансировщике нагрузки на выходном веб-сервере.

Просто совет по безопасности!

Рекомендуется использовать какое-нибудь необычное расширение для вашего контроллера, таким образом злоумышленникам потребуется больше времени, чтобы найти некоторую информацию о сайте.

Поэтому, если вы измените расширение по умолчанию, а также несколько статических параметров в своей структуре, которые могут раскрыть вашу руку, ваша среда MVC может быть полностью неизвестной.

Даже изменить расширение на phpили aspxмогло бы быть хорошей идеей.

На самом деле это безопасность путем обфускации, но это не противоположность хорошей безопасности. Может помочь наложение безопасности посредством неизвестности поверх уже защищенной системы. Есть интересные плюсы и минусы безопасности за счет обфускации, и когда они оба могут использоваться в Интернете.