Статичний вміст
За замовчуванням Spring Boot обробляє статичний вміст з каталогу /static
(або /public
або
/resources
, або /META-INF/resources
) у classpath або з кореня ServletContext
.
Фреймворк використовує ResourceHttpRequestHandler
із Spring MVC, тому ти можеш змінити цю логіку
роботи, додавши власний WebMvcConfigurer
та перевизначивши метод addResourceHandlers
.
В автономному вебдодатку стандартний сервлет із контейнера не активовано. Його можна активувати за допомогою властивості
server.servlet.register-default-servlet
.
Стандартний сервлет виступає в ролі запасного варіанту,
обробляючи вміст з кореня ServletContext
якщо Spring не буде обробляти його. У більшості випадків
такого не відбувається (якщо не змінити стандартну конфігурацію MVC), тому що Spring завжди здатний обробляти запити
через DispatcherServlet
.
За замовчуванням ресурси відображаються на /**
, але можна
тонко налаштувати це відображення через властивість spring.mvc.static-path-pattern
. Наприклад,
переміщення всіх ресурсів до /resources/**
можна виконати так:
spring.mvc.static-path-pattern=/resources/**
spring:
mvc:
static-path-pattern: "/resources/**"
Ти також можеш налаштовувати розташування статичних ресурсів за допомогою властивості spring.web.resources.static-locations
(замінивши значення за замовчуванням на список розташування каталогів). Кореневий шлях контексту сервлета,
"/"
, автоматично додається як місце розташування.
На додаток до "стандартних" статичних
розташування ресурсів, згаданих раніше, особливе місце відводиться вмісті Webjars. Будь-які
ресурси шляхом /webjars/**
обробляються з jar-файлів, якщо вони упаковані у формат Webjars.
src/main/webapp
, якщо програма
упакована у вигляді jar-файлу. Хоча цей каталог є загальноприйнятим стандартом, він працює виключно
з упаковкою в war, і він мовчки ігнорується більшістю інструментальних засобів збирання, якщо генерується jar-файл.
Spring Boot також підтримує розширений функціонал роботи з ресурсами, що надаються Spring MVC, що дозволяє використовувати такі сценарії, як відключення кешування статичних ресурсів або використання URL-адрес для Webjars, які не залежать від версії.
Щоб використовувати URL-адреси Webjars, які не залежать від версії, додай
залежність webjars-locator-core
. Потім оголоси свій Webjar. На прикладі jQuery додавання "/webjars/jquery/jquery.min.js"
призводить до "/webjars/jquery/x.y.z/jquery.min.js"
, де x.y.z
— версія Webjar.
webjars-locator-jboss-vfs
замість webjars-locator-core
. В іншому випадку всі Webjars дозволяються як 404
.
Для використання функції відключення кешування в наступній конфігурації налаштовано рішення для відключення
кешування всіх статичних ресурсів шляхом додавання хешу вмісту, наприклад < link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>
, до URL-адреси:
spring.web.resources.chain.strategy.content.enabled=true
spring.web.resources.chain.strategy.content.paths=/**
spring:
web:
resources:
chain:
strategy:
content:
enabled: true
paths: "/**"
ResourceUrlEncodingFilter
, який автоматично конфігурується для Thymeleaf та FreeMarker. Слід вручну
оголосити цей фільтр під час використання JSP. Інші шаблонізатори наразі не підтримуються в автоматичному
порядку, але їх підтримку можна забезпечити за допомогою кастомних шаблонних макросів/допоміжних класів та
використання ResourceUrlProvider
.
При динамічному завантаженні ресурсів, наприклад, за допомогою завантажувача модулів JavaScript, перейменування файлів неможливе. Тому підтримуються інші стратегії, які можна комбінувати. Стратегія з використанням "фіксації (fixed)" додає статичний рядок версії до URL-адреси без зміни імені файлу, як показано в наступному прикладі:
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"
При такій конфігурації модулі JavaScript, розташовані в каталозі " /js/lib/"
, використовують
стратегію фіксованого версіонування ("/v12/js/lib/mymodule.js"
), в той час як інші ресурси, як і
раніше, використовують стратегію на основі вмісту (<link
href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>
).
Додаткові опції, що підтримуються, див. WebProperties.Resources
.
Ця функція була детально описана в довідковій документації Spring Framework.
Початкова сторінка
Spring Boot підтримує як статичні, так і шаблонні початкові сторінки. Спочатку фреймворк шукає файл index.html
у налаштованих місцях статичного вмісту. Якщо шаблон не знайдено, він шукає шаблон index
. Якщо один
з них буде знайдений, то він буде автоматично використаний як початкова сторінка програми.
Кастомний Favicon
Як і у випадку з іншими статичними ресурсами, Spring Boot перевіряє наявність favicon.ico
у
конфігурованих місцях статичного контенту. Якщо такий файл присутній, він автоматично використовується як значок
вебсторінки (favicon) для програми.
Зіставлення шляхів та узгодження вмісту
Spring MVC може зіставляти вхідні HTTP-запити з обробниками, переглядаючи шлях запиту та зіставляючи його з відображеннями, визначеними
в додатку (наприклад, анотаціями @GetMapping
для методів контролера).
Spring Boot за замовчуванням відключає зіставлення суфіксальних шаблонів, що означає, що запити типу "GET
/projects/spring-boot.json"
не будуть зіставлені з відображенням @GetMapping("/projects/spring-boot")
.
Це вважається найбільш оптимальним методом додатків Spring MVC. У минулому ця функція була корисною в основному
для HTTP-клієнтів, які не надсилали належні заголовки запиту "Accept"; необхідно було переконатися, що клієнту
надіслано коректний тип вмісту. В даний час узгодження вмісту стало набагато надійнішим.
Існують й інші способи розібратися з HTTP-клієнтами, які не завжди надсилають правильні заголовки запиту
"Accept". Замість використання суфіксальної відповідності можна використовувати параметр запиту, щоб запити типу
"GET /projects/spring-boot?format=json"
були гарантовано зіставлені з @GetMapping("/projects/spring-boot"
)
:
spring.mvc.contentnegotiation.favor-parameter=true
spring:
mvc:
contentnegotiation:
favor-parameter: true
Або якщо ти волієш використовувати інше ім'я параметра:
spring.mvc.contentnegotiation.favor-parameter=true
spring.mvc.contentnegotiation.parameter-name=myparam
spring:
mvc:
contentnegotiation:
favor-parameter: true
parameter-name: "myparam"
Більшість стандартних типів середовища передачі даних підтримуються "з коробки", але ти також можеш визначати нові:
spring. mvc.contentnegotiation.media-types.markdown=text/markdown
spring:
mvc:
contentnegotiation:
media-types:
markdown: "text/markdown"
Зіставлення суфіксальних шаблонів зі зразком застаріло і буде видалено в майбутньому випуску. Якщо тобі зрозумілі всі застереження і все ж таки ти хочеш, щоб програма використовувала суфіксальне зіставлення шаблонів зі зразком, необхідно виконати наступну конфігурацію:
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
До того ж, замість відкриття всіх суфіксальних шаблонів більш надійним методом буде забезпечення підтримки виключно зареєстрованих суфіксальних шаблонів:
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
Починаючи з версії Spring Framework 5.3, Spring MVC підтримує кілька стратегій реалізації для зіставлення шляхів
запиту з обробниками контролера. Раніше вона підтримувала лише стратегію AntPathMatcher
, але тепер
також пропонує PathPatternParser
. Spring Boot тепер передбачає конфігураційну властивість, що
забезпечує вибір та підключення нової стратегії:
spring.mvc.pathmatch.matching- strategy=path-pattern-parser
spring:
mvc:
pathmatch:
matching-strategy: "path-pattern-parser"
Для отримання більш детальної інформації про те, чому слід звернути увагу на цю нову реалізацію, див. спеціальний пост у блозі.
PathPatternParser
є оптимізованою реалізацією, але обмежує
використання деяких варіантів шаблонів шляхів і несумісна зі зіставленням суфіксальних шаблонів (spring.mvc.pathmatch.use-suffix-pattern
,
spring.mvc.pathmatch.use-registered-suffix-pattern
) або відображенням
DispatcherServlet
із префіксом сервлета (spring.mvc.servlet.path
).
ConfigurableWebBindingInitializer
Spring MVC використовує WebBindingInitializer
для ініціалізації WebDataBinder
для
конкретного запиту. Якщо ти створиш свій власний ConfigurableWebBindingInitializer
, позначений
анотацією @Bean
, Spring Boot автоматично конфігурує Spring MVC для його використання.