Web.xml:url-pattern 标签彼此相关吗?

发布于 2024-08-30 11:23:00 字数 691 浏览 5 评论 0原文

   <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 web 服务)。只是想知道 web-resource-collection 中的 url-pattern 是否相对于 servlet-mapping 中的 url-pattern代码>.

   <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>

This is an excerpt from web.xml (using it to configure a jboss/tomcat webservice). Just wondering if the url-pattern in web-resource-collection is relative to the url-pattern in servlet-mapping.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

负佳期 2024-09-06 11:23:00

用于为给定请求选择约束的url-pattern与任何事物都无关。 Servlet 规范中有趣的部分是:

SRV.12.8.3 处理请求

当 Servlet 容器接收到
请求,应使用算法
SRV.11.1 中描述的选择
上定义的约束(如果有)
与以下内容最匹配的 url-pattern
请求 URI。
如果没有约束
选择后,容器应接受
的请求。否则容器
应确定 HTTP 方法是否
该请求被限制在
选定的图案。如果不是,则
请求应被接受。否则,
该请求必须满足
适用于 http-method 的约束
url-pattern 处。两者都
必须满足以下规则
要求接受的请求以及
分派到关联的 servlet。

和:

SRV.11.1 URL 路径的使用

收到客户端请求后,Web 容器确定 Web 应用程序
将其转发到的位置。所选的 Web 应用程序必须具有最长的
与请求 URL 开头匹配的上下文路径。 URL 的匹配部分
是映射到 servlet 时的上下文路径。

Web 容器接下来必须使用 servlet 来处理请求
路径映射过程如下所述。

用于映射到 servlet 的路径是来自请求的请求 URL
对象减去上下文路径和路径参数。 URL路径映射
以下规则按顺序使用。第一个成功的匹配将被使用,不再继续
尝试的匹配:

  1. 容器将尝试找到与请求路径完全匹配的
    Servlet 的路径。成功的匹配将选择 servlet。
  2. 容器将递归地尝试匹配最长的路径前缀。这样就完成了
    通过使用“/”字符一次沿着路径树向下移动一个目录
    路径分隔符。最长的匹配决定选择的 servlet。
  3. 如果 URL 路径中的最后一段包含扩展名(例如 .jsp),servlet 容器将尝试匹配处理该扩展名请求的 servlet。
    扩展名定义为最后一个“.”之后的最后一个段的部分。字符-
    角色。
  4. 如果前三个规则都没有导致 servlet 匹配,则容器将
    尝试提供适合所请求资源的内容。如果是“默认”
    servlet 是为应用程序定义的,它将被使用。

SRV.11.2 映射规范

在Web应用程序部署描述符中,使用以下语法来定义
映射:

  • 使用以“/”字符开头并以“/*”后缀结尾的字符串
    用于路径映射。
  • 以“*”开头的字符串。前缀用作扩展映射。
  • 仅包含“/”字符的字符串表示“默认”servlet
    该应用程序。在本例中,servlet 路径是请求 URI 减去上下文路径,并且路径信息为 null。
  • 所有其他字符串仅用于精确匹配。

The url-pattern used to select the constraints for a given request are not relative to anything. The interesting parts of the Servlet spec here are:

SRV.12.8.3 Processing Requests

When a Servlet container receives a
request, it shall use the algorithm
described in SRV.11.1 to select the
constraints (if any) defined on the
url-pattern that is the best match to
the request URI.
If no constraints are
selected, the container shall accept
the request. Otherwise the container
shall determine if the HTTP method of
the request is constrained at the
selected pattern. If it is not, the
request shall be accepted. Otherwise,
the request must satisfy the
constraints that apply to the http-method
at the url-pattern. Both of the
following rules must be satisfied for
the request to be accepted and
dispatched to the associated servlet.

And:

SRV.11.1 Use of URL Paths

Upon receipt of a client request, the Web container determines the Web application
to which to forward it. The Web application selected must have the longest
context path that matches the start of the request URL. The matched part of the URL
is the context path when mapping to servlets.

The Web container next must locate the servlet to process the request using
the path mapping procedure described below
.

The path used for mapping to a servlet is the request URL from the request
object minus the context path and the path parameters. The URL path mapping
rules below are used in order. The first successful match is used with no further
matches attempted:

  1. The container will try to find an exact match of the path of the request to the
    path of the servlet. A successful match selects the servlet.
  2. The container will recursively try to match the longest path-prefix. This is done
    by stepping down the path tree a directory at a time, using the ’/’ character as
    a path separator. The longest match determines the servlet selected.
  3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension.
    An extension is defined as the part of the last segment after the last ’.’ char-
    acter.
  4. If neither of the previous three rules result in a servlet match, the container will
    attempt to serve content appropriate for the resource requested. If a "default"
    servlet is defined for the application, it will be used.

SRV.11.2 Specification of Mappings

In the Web application deployment descriptor, the following syntax is used to define
mappings:

  • A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used
    for path mapping.
  • A string beginning with a ‘*.’ prefix is used as an extension mapping.
  • A string containing only the ’/’ character indicates the "default" servlet of
    the application. In this case the servlet path is the request URI minus the context path and the path info is null.
  • All other strings are used for exact matches only.
那请放手 2024-09-06 11:23:00

对我来说,security-constraint/web-resource-collection/url-patternservlet-mapping/url-pattern 是有道理的,原因如下:web.xml 中可能有多个 servlet-mapping 元素,在这种情况下,不清楚是哪个 servlet-mapping/url-pattern< /em> 用于解析相对 URI,如果是的话。
(只是猜测 - 我还没有在 tomcat 中使用安全约束)。

It would make sense to me that the security-constraint/web-resource-collection/url-pattern is not relative to the servlet-mapping/url-pattern, for the following reason: there can be several servlet-mapping elements in web.xml, in which case it would not be clear which servlet-mapping/url-pattern to take to resolve the relative URI, were it one.
(Just a guess - I have not used security constraints in tomcat yet).

阳光的暖冬 2024-09-06 11:23:00

不,它们彼此没有关系;无法将给定的 servlet-mapping 绑定到安全约束。两者都应用于给定的 URL 模式,安全约束也可以仅应用于特定的 HTTP 方法(GET、POST...),因此它们是相当独立的。

这两个元素均在 Servlet 规范 中定义和描述。您可能需要阅读有关安全性的 SRV.12.8 部分以及有关 url-pattern 元素的详细信息。

No, they are not relative to each other; there is no way to bind a given servlet-mapping to a security-constraint. Both are applied to a given URL pattern, security constraint can also be applied only to specific HTTP methods (GET, POST, ...) so they are quite independent.

Both elements are defined and described in the Servlet specification. You might want to read sections SRV.12.8 about security, and details about the url-pattern element.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文