Статичний вміст

За умовчанням 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/** можна виконати так:

Properties
spring.mvc.static-path-pattern=/resources/**
Yaml
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.

Якщо ви використовуєте JBoss, то потрібно оголосити залежність webjars-locator-jboss-vfs замість webjars-locator-core. В іншому випадку всі Webjars дозволяються як 404.

Для використання функції відключення кешування в наступній конфігурації налаштовано рішення для відключення кешування всіх статичних ресурсів шляхом додавання хешу вмісту, наприклад < link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>, в URL-адресу:

Properties
spring.web.resources.chain.strategy.content.enabled=true spring.web.resources.chain.strategy.content.paths=/**
Yaml
spring: web: resources: chain: stratégia: content: enabled: true paths: "/**"
Посилання на ресурси переписуються в шаблонах під час виконання завдяки ResourceUrlEncodingFilter, який автоматично конфігурується для Thymeleaf та FreeMarker. Слід вручну оголосити цей фільтр під час використання JSP. Інші шаблонізатори в даний час не підтримуються в автоматичному порядку, але їх підтримку можна забезпечити за допомогою кастомних шаблонних макросів/допоміжних класів та використання ResourceUrlProvider.

При динамічному завантаженні ресурсів, наприклад, за допомогою завантажувача модулів JavaScript, перейменування файлів неможливе. Тому підтримуються інші стратегії, які можна комбінувати. Стратегія з використанням "фіксації (fixed)" додає статичний рядок версії до URL-адреси без зміни імені файлу, як показано в наступному прикладі:

Properties
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
Yaml
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.

Ця функція була детально описана у спеціальному посту в блозі a> і в довідкова документація Spring Framework.

Початкова сторінка

Spring Boot підтримує як статичні, так і шаблонні початкові сторінки. Спочатку фреймворк шукає файл index.html у налаштованих місцях статичного вмісту. Якщо шаблон не знайдено, він шукає шаблон index. Якщо один з них буде знайдений, то він буде автоматично використаний як початкова сторінка програми.

Кастомний Favicon

Як і у випадку з іншими статичними ресурсами, Spring Boot перевіряє наявність favicon.ico у конфігурованих місцях статичного контенту. Якщо такий файл присутній, він автоматично використовується як значок веб-сторінки (favicon) для програми. переглядаючи шлях запиту та зіставляючи його з відображеннями, визначеними в додатку (наприклад, анотаціями @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" ):

Properties
spring.mvc.contentnegotiation.favor-parameter=true
Yaml
spring: mvc: contentnegotiation: favor-parameter: true 

Або якщо ви волієте використовувати інше ім'я параметра:

Properties
spring.mvc.contentnegotiation.favor-parameter=true spring.mvc.contentnegotiation.parameter-name=myparam
Yaml
spring: mvc: contentnegotiation: favor-parameter: true parameter-name: "myparam"

Більшість стандартних типів середовища передачі даних підтримуються "з коробки", але ви також можете визначати нові:

Properties
spring. mvc.contentnegotiation.media-types.markdown=text/markdown
Yaml
spring: mvc: contentnegotiation: media-types: markdown: "text/markdown"

Зіставлення суфіксальних шаблонів зі зразком застаріло і буде видалено в майбутньому випуску. Якщо вам зрозумілі всі застереження і все ж таки ви хочете, щоб програма використовувала суфіксальне зіставлення шаблонів зі зразком, необхідно виконати наступну конфігурацію:

Properties
spring.mvc.contentnegotiation.favor-path-extension=true spring.mvc.pathmatch.use-suffix-pattern=true
Yaml
spring: mvc: contentnegotiation: favor-path-extension: true pathmatch: use-suffix-pattern: true

Крім того, замість відкриття всіх суфіксальних шаблонів більш надійним методом буде забезпечення підтримки виключно зареєстрованих суфіксальних шаблонів:

Properties
spring.mvc.contentnegotiation.favor-path-extension=true spring.mvc.pathmatch.use-registered-suffix-pattern=true
Yaml
spring: mvc: contentnegotiation: favor-path-extension: true pathmatch: use-registered-suffix-pattern: true

Починаючи з версії Spring Framework 5.3, Spring MVC підтримує кілька стратегій реалізації для зіставлення шляхів запиту з обробниками контролера. Раніше вона підтримувала лише стратегію AntPathMatcher, але тепер також пропонує PathPatternParser. Spring Boot тепер передбачає конфігураційну властивість, що забезпечує вибір та підключення нової стратегії:

Properties
spring.mvc.pathmatch.matching- strategy=path-pattern-parser
Yaml
spring: mvc : pathmatch: matching-strategy: "path-pattern-parser"

Для отримання більш детальної інформації про те, чому слід звернути увагу на цю нову реалізацію, див. спеціальний пост у блозі.

PathPatternParser є оптимізованою реалізацією, але обмежує використання деяких варіантів шаблонів шляхів і несумісна зі зіставленням суфіксальних шаблонів (< code>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 для його використання.