Подтвердить что ты не робот

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

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

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

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

4b9b3361

Ответ 1

Насколько мне известно, это соглашение было распространено 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, иногда просто потому, что люди были довольны этим).

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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