Фільтри

Браузери можуть надсилати дані форми лише через HTTP-метод GET або HTTP-метод POST, але небраузерні клієнти можуть використовувати HTTP-методи PUT, PATCH і DELETE. Servlet API вимагає, щоб методи ServletRequest.getParameter*() підтримували доступ до полів форми лише для HTTP-методу POST.

Модуль spring-web надає FormContentFilter для перехоплення запитів HTTP-методів PUT, PATCH та DELETE з типом вмісту application/x-www-form-urlencoded, читання даних форми з тіла запиту та обгортання ServletRequest, щоб забезпечити доступ до цих даних форми через сімейство методів ServletRequest.getParameter*().

Заголовки, що передалися

Поки запит проходить через проксі-сервери (наприклад, розподільник навантаження), хост, порт та схема можуть змінюватися, і це ускладнює створення посилань, що вказують на правильний хост, порт та схему з погляду клієнта.

Специфікація RFC 7239 визначає Forwarded HTTP-заголовок, який проксі-сервери можуть використовувати для надання інформації про вихідний запит. Існують й інші нестандартні заголовки, включно з X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto, X -Forwarded-Ssl та X-Forwarded-Prefix.

ForwardedHeaderFilter — це фільтр сервлетів, який модифікує запит, щоб: а) змінити хост, порт і схему на основі заголовків Forwarded; і б) видалити ці заголовки, щоб виключити подальший їхній вплив. Фільтр діє з урахуванням обгортання запиту, тому його потрібно впорядкувати перед іншими фільтрами, такими як RequestContextFilter, які повинні працювати зі зміненим, а не оригінальним запитом.

Існують запобіжні заходи для заголовків, що передаються, оскільки програма не може знати, чи були заголовки додані проксі-сервером, як передбачалося, або шкідливим клієнтом. Ось чому проксі-сервер на межі довіри потрібно налаштувати на видалення ненадійних Forwarded заголовків, що надходять ззовні. Також можна налаштувати ForwardedHeaderFilter з параметром removeOnly=true, і в цьому випадку він видалятиме, але не використовуватиме заголовки.

Для забезпечення підтримки асинхронних запитів та диспетчеризації помилок цей фільтр має бути зіставлений з DispatcherType.ASYNC, а також DispatcherType.ERROR. При використанні AbstractAnnotationConfigDispatcherServletInitializer зі Spring Framework всі фільтри автоматично реєструються для будь-яких типів диспетчеризації. Однак під час реєстрації фільтра через web.xml або в Spring Boot через FilterRegistrationBean обов'язково активуй DispatcherType.ASYNC та DispatcherType.ERROR на додаток до DispatcherType.REQUEST.

Поверхневий ETag

Фільтр ShallowEtagHeaderFilter створює "поверхневий" ETag шляхом кешування вмісту, записаного до відповіді, та обчислення MD5-хеша з нього. Під час наступного надсилання клієнтом фільтр робить те саме, але водночас порівнює обчислене значення із заголовком запиту If-None-Match. Якщо вони рівні, повертає 304 (NOT_MODIFIED).

Ця стратегія заощаджує пропускну спроможність мережі, але не ресурси процесора, тому що для кожного запиту необхідно обчислити повну відповідь. Інші стратегії на рівні контролера, описані раніше, дозволяють уникнути обчислень.

Цей фільтр має параметр writeWeakETag, який налаштовує фільтр на запис нестрогих ETag, аналогічних наступним: W/"02a2d595e6ed9a0b24f027f2b63b134d6"RFC 7232, розділ 2.3).

Для підтримки асинхронних запитів цей фільтр потрібно відобразити на DispatcherType.ASYNC, щоб фільтр міг відкласти обробку та успішно згенерувати ETag до кінця останньої асинхронної диспетчеризації. При використанні AbstractAnnotationConfigDispatcherServletInitializer зі Spring Framework всі фільтри автоматично реєструються для всіх типів диспетчеризації. Однак якщо ти реєструєш фільтр через web.xml або в Spring Boot через FilterRegistrationBean, обов'язково увімкни до складу DispatcherType.ASYNC.

CORS

Spring MVC забезпечує тонку підтримку конфігурації CORS за допомогою анотацій для контролерів. Однак при використанні зі Spring Security радимо покладатися на вбудований CorsFilter, який має бути розташований попереду ланцюжка фільтрів Spring Security.

Детальнішу інформацію див. у розділах, присвячених CORS та CORS-фільтру.