Web.xml: являются ли теги url-pattern относительно друг друга? - PullRequest
3 голосов
/ 26 апреля 2010
   <servlet-mapping>
      <servlet-name>myName</servlet-name>
      <url-pattern>/aName</url-pattern>
   </servlet-mapping>

    <security-constraint>

            <web-resource-collection>

                    ...

                    <url-pattern>
                            /*
                    </url-pattern>

            </web-resource-collection>

             ...

    </security-constraint>

Это выдержка из файла web.xml (используется для настройки веб-службы jboss / tomcat). Просто интересно, если url-pattern в web-resource-collection относительно url-pattern в servlet-mapping.

Ответы [ 3 ]

6 голосов
/ 01 мая 2010

url-pattern, используемый для выбора ограничений для данного запроса, не относится ни к чему. Интересные части спецификации Servlet:

SRV.12.8.3 Обработка запросов

Когда контейнер сервлетов получает запрос, он должен использовать алгоритм описано в SRV.11.1, чтобы выбрать ограничения (если таковые имеются), определенные на url-pattern это лучший матч URI запроса. Если нет ограничений выбран, контейнер должен принять запрос. В противном случае контейнер должен определить, если метод HTTP запрос ограничен в выбранный образец. Если это не так, запрос должен быть принят. Иначе, запрос должен удовлетворить ограничения, которые применяются к http-method на url-pattern. Оба из следующие правила должны быть выполнены для запрос должен быть принят и отправлен в связанный сервлет.

И

SRV.11.1 Использование путей URL

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

Веб-контейнер затем должен найти сервлет для обработки запроса с использованием процедура отображения пути описана ниже .

Путь, используемый для сопоставления с сервлетом, является URL-адресом запроса. Объект минус контекстный путь и параметры пути. Отображение пути URL Правила ниже используются по порядку. Первый успешный матч используется без дальнейшего попытки совпадений:

  1. Контейнер попытается найти точное соответствие пути запроса к путь сервлета. Успешное совпадение выбирает сервлет.
  2. Контейнер будет рекурсивно пытаться найти самый длинный префикс пути. Готово шагая вниз по дереву пути к каталогу за раз, используя символ «/» как разделитель пути. Самое длинное совпадение определяет выбранный сервлет.
  3. Если последний сегмент в пути URL-адреса содержит расширение (например, .jsp), контейнер сервлета попытается сопоставить сервлет, который обрабатывает запросы на расширение. Расширение определяется как часть последнего сегмента после последнего символа "." Acter.
  4. Если ни одно из трех предыдущих правил не приводит к совпадению сервлета, контейнер будет попытаться предоставить контент, соответствующий запрашиваемому ресурсу. Если «по умолчанию» сервлет определен для приложения, он будет использоваться.

SRV.11.2 Спецификация отображений

В дескрипторе развертывания веб-приложения следующий синтаксис используется для определения Отображения:

  • Используется строка, начинающаяся с символа ‘/’ и заканчивающаяся суффиксом ‘/ *’ для отображения пути.
  • Строка, начинающаяся с префикса ‘*.’, Используется как отображение расширения.
  • Строка, содержащая только символ ’/’, обозначает сервлет «по умолчанию» приложение. В этом случае путь сервлета является URI запроса минус путь контекста, а информация о пути равна нулю.
  • Все остальные строки используются только для точных совпадений.
5 голосов
/ 27 апреля 2010

Было бы разумно, чтобы ограничение безопасности / коллекция веб-ресурсов / шаблон URL-адреса было , а не относительно сопоставления сервлета / URL-адреса. шаблон по следующей причине: в файле web.xml может быть несколько элементов servlet-mapping , и в этом случае неясно, какой servlet-mapping / url-pattern чтобы разрешить относительный URI, если он один. (Просто предположение - я еще не использовал ограничения безопасности в tomcat).

1 голос
/ 28 апреля 2010

Нет, они не относятся друг к другу; нет никакого способа связать данное отображение сервлета с ограничением безопасности . Оба применяются к заданному шаблону URL, ограничения безопасности также могут применяться только к определенным методам HTTP (GET, POST, ...), поэтому они совершенно независимы.

Оба элемента определены и описаны в спецификации Servlet . Возможно, вы захотите прочитать разделы SRV.12.8 о безопасности и подробности об элементе url-pattern.

...