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.