Contenido estático
De forma predeterminada, Spring Boot procesa contenido estático desde el directorio /static
(o /public
o /resources
, o /META-INF/resources
) en el classpath o desde la raíz ServletContext
. El marco utiliza ResourceHttpRequestHandler
de Spring MVC, por lo que puede cambiar esta lógica agregando su propio WebMvcConfigurer
y anulando el método addResourceHandlers
.
En una aplicación web independiente, el servlet estándar del contenedor no está activado. Se puede habilitar usando la propiedad server.servlet.register-default-servlet
.
El servlet predeterminado actúa como un respaldo, procesando el contenido desde la raíz ServletContext
, si Spring no lo maneja. En la mayoría de los casos, esto no sucede (a menos que cambie la configuración MVC predeterminada) porque Spring siempre puede manejar solicitudes a través de DispatcherServlet
.
De forma predeterminada, los recursos se asignan a /**
, pero puede ajustar esta asignación a través de la propiedad spring.mvc.static-path-pattern
. Por ejemplo, mover todos los recursos a /resources/**
se puede hacer de la siguiente manera:
spring.mvc.static-path-pattern=/resources/**
spring: mvc: static-path-pattern: "/resources/**"
También puedes personalizar la ubicación de recursos estáticos con el uso de la propiedad spring.web.resources.static-locations
(reemplazando los valores predeterminados con una lista de ubicaciones de directorios). La ruta raíz del contexto del servlet, "/"
, se agrega automáticamente como ubicación.
Además de las ubicaciones de recursos estáticos "estándar" mencionadas anteriormente, hay un lugar especial otorgado al contenido de Webjars. Cualquier recurso con una ruta en /webjars/**
se procesa a partir de archivos jar si están empaquetados en formato Webjars.
src/main/webapp
si la aplicación está empaquetada como un archivo jar. Aunque este directorio es un estándar generalmente aceptado, funciona exclusivamente con paquetes war y la mayoría de las herramientas de compilación lo ignoran silenciosamente si se genera un archivo jar.
Spring Boot también admite funciones avanzadas que trabajan con los recursos proporcionados de Spring MVC, lo que permite escenarios como deshabilitar el almacenamiento en caché de recursos estáticos o usar URL independientes de la versión para Webjars.
Para usar URL de Webjars independientes de la versión, agregue el webjars-locator-core
dependencia. Luego declara tu Webjar. Usando jQuery como ejemplo, agregar "/webjars/jquery/jquery.min.js"
da como resultado "/webjars/jquery/x.y.z/jquery.min.js"
, donde x.y.z
– versión Webjar.
webjars-locator-jboss-vfs
en lugar de
webjars-locator-core
. De lo contrario, todos los Webjars se resuelven como
404
.
Para utilizar la función deshabilitar el almacenamiento en caché, se configura la siguiente configuración para deshabilitar el almacenamiento en caché de todos los recursos estáticos agregando un hash del contenido, como <link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>
, a la URL:
spring.web.resources.chain.strategy.content.enabled=true
spring.web.resources.chain.strategy.content.paths=/**
web:
resources:
chain:
strategy:
content:
enabled: true
paths: "/**"
ResourceUrlEncodingFilter
, que se configura automáticamente para Thymeleaf y FreeMarker. Debe declarar manualmente este filtro cuando utilice JSP. Actualmente, otros motores de plantillas no son compatibles automáticamente, pero se pueden admitir usando macros de plantillas personalizadas/clases auxiliares y usando
ResourceUrlProvider
.
Al cargar recursos dinámicamente, por ejemplo, usando el cargador de módulos JavaScript, no es posible cambiar el nombre de los archivos. Por lo tanto, se admiten otras estrategias y se pueden combinar. La estrategia "fija" agrega una cadena de versión estática a la URL sin cambiar el nombre del archivo, como se muestra en el siguiente ejemplo:
spring.web.resources.chain.strategy.content.enabled=true
spring.web.resources.chain.strategy.content.paths=/**
spring.web.resources.chain.strategy.fixed.enabled=true
spring.web.resources.chain.strategy.fixed.paths=/js/lib/
spring.web.resources.chain.strategy.fixed.version=v12
spring:
web:
resources:
chain:
strategy:
content:
enabled: true
paths: "/**"
fixed:
enabled: true
paths: "/js/lib/"
version: "v12"
Con esta configuración, los módulos JavaScript ubicados en el directorio"/js/lib/"
, use una estrategia de control de versiones fija ("/v12/js/lib/mymodule.js"
), mientras que otros recursos aún usan un contenido ( <link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>
).
Consulta para conocer opciones adicionales admitidas WebProperties.Resources
.
Esta función se ha descrito en detalle en un artículo especial. publicación de blog y en documentación de referencia Spring Framework.
Página de inicio
Spring Boot admite páginas de inicio estáticas y de plantilla. El marco primero busca el archivo index.html
en las ubicaciones de contenido estático configuradas. Si no se encuentra dicho patrón, busca el patrón index
. Si se encuentra uno de ellos, se utilizará automáticamente como página de inicio de la aplicación.
Favicon personalizado
Al igual que con otros recursos estáticos, Spring Boot comprueba la presencia de favicon.ico
en ubicaciones de contenido estático configuradas. Si dicho archivo está presente, se utiliza automáticamente como icono de página web (favicon) para la aplicación.
Mapeo de ruta y negociación de contenido
Spring MVC puede asignar solicitudes HTTP entrantes a controladores que observan la ruta de la solicitud y la comparan con las asignaciones definidas en la aplicación (por ejemplo, anotaciones @GetMapping
para los métodos del controlador).
Spring Boot deshabilita la coincidencia de patrones de sufijos mediante predeterminado, lo que significa que solicitudes como "GET /projects/spring-boot.json"
no se asignarán a asignaciones @GetMapping("/projects/spring-boot")
. Esta se considera la mejor práctica para aplicaciones Spring MVC. En el pasado, esta característica era útil principalmente para clientes HTTP que no enviaban encabezados de solicitud "Aceptar" adecuados; era necesario asegurarse de que se enviara el tipo de contenido correcto al cliente. La negociación de contenido ahora es mucho más confiable.
Hay otras formas de tratar con clientes HTTP que no siempre envían los encabezados de solicitud "Aceptar" correctos. En lugar de utilizar la coincidencia de sufijos, puede utilizar un parámetro de consulta para garantizar que solicitudes como "GET /projects/spring-boot?format=json"
coincidan con @GetMapping("/projects/spring-boot")
:
spring.mvc.contentnegotiation.favor-parameter=true
spring:
mvc:
contentnegotiation:
favor-parameter: true
O si prefiere utilizar un nombre de parámetro diferente:
spring.mvc.contentnegotiation.favor-parameter=true
spring.mvc.contentnegotiation.parameter-name=myparam
spring:
mvc:
contentnegotiation:
favor-parameter:
true nombre-parámetro: "myparam"
La mayoría de los tipos de medios estándar son compatibles desde el primer momento, pero también puedes definir otros nuevos:
spring.mvc.contentnegotiation.favor-path-extension=true
spring.mvc.pathmatch.use-suffix-pattern=true
spring:
mvc:
contentnegotiation:
favor-path-extension: true
pathmatch:
use-suffix-pattern: true
Coincidencia de patrones de sufijo está en desuso y se eliminará en una versión futura. Si comprende las advertencias y aún desea que su aplicación utilice la coincidencia de patrones de sufijo, debe realizar la siguiente configuración:
spring.mvc.contentnegotiation.favor-path-extension=true
spring.mvc.pathmatch.use-suffix-pattern=true
spring:
mvc:
contentnegotiation:
favor-path-extension: true
pathmatch:
use-suffix-pattern: true
Además, en lugar de abrir todos los patrones de sufijos, un método más confiable sería admitir solo patrones de sufijos registrados:
spring.mvc.contentnegotiation.favor-path-extension=true
spring.mvc.pathmatch.use-registered-suffix-pattern=true
spring:
mvc:
contentnegotiation:
favor-path-extension: true
pathmatch:
use-registered-suffix-pattern: true
A partir de Spring Framework 5.3, Spring MVC admite varias estrategias de implementación para asignar rutas de solicitud a controladores. Anteriormente solo admitía la estrategia AntPathMatcher
, pero ahora también ofrece PathPatternParser
. Spring Boot ahora proporciona una propiedad de configuración que le permite seleccionar y habilitar una nueva estrategia:
spring.mvc. pathmatch.matching-estrategia=path-pattern-parser
spring:
mvc:
pathmatch:
matching-strategy: "path-pattern-parser"
Para obtener más información sobre por qué debería prestar atención a esta nueva implementación , consulte la publicación de blog dedicada.
PathPatternParser
es una implementación optimizada, pero limita el uso de algunas variantes de patrones de ruta y no es compatible con el sufijo coincidencia de patrones (
spring.mvc.pathmatch.use-suffix-pattern
,
spring.mvc.pathmatch.use-registered-suffix-pattern
) o mapeo
DispatcherServlet
con prefijo de servlet (
spring.mvc.servlet.path
).
ConfigurableWebBindingInitializer
Spring MVC usa WebBindingInitializer
para inicialice WebDataBinder
para una solicitud específica. Si crea su propio ConfigurableWebBindingInitializer
marcado con la anotación @Bean
, Spring Boot configurará automáticamente Spring MVC para usar eso.
GO TO FULL VERSION