Tomcat 在 Spring MVC 应用程序上提供静态资源

发布于 2024-09-24 04:24:12 字数 547 浏览 4 评论 0原文

我正在构建一个 Spring MVC 应用程序,并且 frontController servlet 映射在“/”中拦截所有请求,我能够从 tomcat 提供静态内容(.js、.css、.png...)不是到了春天。 我的应用程序结构是

-webapp/
   styles/
   images/
   WEB-INF/
          views/

默认的,因为 frontController 映射到我的应用程序的上下文根上,它处理所有请求,但不提供任何静态资源。 静态资源的 mvc 配置如下。

<mvc:resources mapping="/resources/**" location="/"/>

该页面的代码是:

<img src="resources/images/logo.png" />

我需要配置 Tomcat 来为静态资源提供服务没有 spring 交互

有什么建议吗?

I'm building a Spring MVC application, and the frontController servlet is mapped in "/" intercepting all requests, I'd to be able to serve the static contents (.js,.css,.png...) from tomcat and not by Spring.
My app structure is

-webapp/
   styles/
   images/
   WEB-INF/
          views/

By default, because the frontController is mapped on the context root of my app its handles all requests but don't serve any static resource.
The mvc configurarion for static resources is follow.

<mvc:resources mapping="/resources/**" location="/"/>

And the page's code is:

<img src="resources/images/logo.png" />

I need to configure Tomcat to serve the static resources with no spring interaction.

Any suggestion?

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

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

发布评论

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

评论(3

夏花。依旧 2024-10-01 04:24:13

您可以重新映射 tomcats 默认 servlet(处理静态内容),例如

<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/images/*</url-pattern>
</servlet-mapping>

You can remap tomcats default servlet (which handles static content), e.g.

<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/images/*</url-pattern>
</servlet-mapping>
逆流 2024-10-01 04:24:13

查看此邮件列表线程,看看是否这就是你正在寻找的。

Have a look at this mailing list thread and see if that does what you're looking for.

尐籹人 2024-10-01 04:24:13

另一个潜在的解决方案 - 只需将以下内容添加到 Spring DispatcherServlet.xml (Spring 文档)

<mvc:default-servlet-handler/>

此标记允许将 DispatcherServlet 映射到“/”(从而覆盖容器默认 Servlet 的映射),同时仍然允许容器默认 Servlet 处理静态资源请求。它使用“/**”的 URL 映射(给出最低优先顺序)配置 DefaultServletHttpRequestHandler。该处理程序会将所有请求转发到默认 Servlet。

优点(与 @nos 的解决方案相比)

  • URL 重新映射解决方案的行为有所不同,具体取决于您的容器。 Jetty/Tomcat 6 认为这意味着“将 URL/images/* 映射到 WEBAPP/images/”。雄猫6(也许还有其他人)认为这意味着“将 URL/images/ 映射到 WEBAPP/*”,这是一个巨大的安全漏洞。
  • 如果您想从您的网站提供 favicon.ico、robots.txt 等,那么您将拥有
    为它们创建额外的 url 映射。

缺点

  • Spring 处于循环中,这绝对是不必要的。

此外,无论人们喜欢哪种解决方案,我建议将以下内容添加到您的 web.xml 以防止目录列表(例如 URL/图像)

<servlet>
  <servlet-name>default</servlet-name>
  <init-param>
      <param-name>dirAllowed</param-name>
      <param-value>false</param-value>
  </init-param>
</servlet>

Another potential solution - Just add the following to your Spring DispatcherServlet.xml (Spring Docs)

<mvc:default-servlet-handler/>

This tag allows for mapping the DispatcherServlet to "/" (thus overriding the mapping of the container's default Servlet), while still allowing static resource requests to be handled by the container's default Servlet. It configures a DefaultServletHttpRequestHandler with a URL mapping (given a lowest precedence order) of "/**". This handler will forward all requests to the default Servlet.

Pros (as compared to @nos's solution)

  • The URL remapping solution behaves differently depending upon your container. Jetty/Tomcat 6 take that to mean 'map URL/images/* to WEBAPP/images/'. Tomcat < 6 (and maybe others) take that to mean 'map URL/images/ to WEBAPP/*', which is a BIG security breach.
  • If you want to serve a favicon.ico, robots.txt etc. from your site, then you'll have
    to create additional url-mappings for them.

Cons

  • Spring is in the loop, which is definitely something that is unnecessary.

Additionally, irrespective of the solution that one prefers, I'd suggest adding the following to your web.xml to prevent directory listings (on, say URL/images)

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