You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When serving static assets via jettys DefaultServlet I only want CORS headers set on successful (2xx) responses. CORS headers must not be set on error responses as the 404 page is rendered by a framework servlet and would include sensitive application content (cookies, CSRF token).
Current approach:
Jetty 12 EE10
A servlet filter for adding CORS headers mapped to DefaultServlet for REQUEST|FORWARD dispatches
A web.xml for 404 routing to a framework servlet
I tried to solve this issue by using a HttpServletResponseWrapper and setting headers when getOutputStream is called but jetty does not call getOutputStream on empty files. Additionally I looked into registering the filter on the framework servlet for ERROR dispatches, removing the header if the original request URI (jakarta.servlet.error.request_uri) was a static asset path but other kinds of errors will not forward to the framework servlet.
As these approaches seem brittle, what would be the most idiomatic and resilient approach to realize this behavior?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
When serving static assets via jettys DefaultServlet I only want CORS headers set on successful (2xx) responses. CORS headers must not be set on error responses as the 404 page is rendered by a framework servlet and would include sensitive application content (cookies, CSRF token).
Current approach:
DefaultServletforREQUEST|FORWARDdispatchesI tried to solve this issue by using a
HttpServletResponseWrapperand setting headers whengetOutputStreamis called but jetty does not callgetOutputStreamon empty files. Additionally I looked into registering the filter on the framework servlet forERRORdispatches, removing the header if the original request URI (jakarta.servlet.error.request_uri) was a static asset path but other kinds of errors will not forward to the framework servlet.As these approaches seem brittle, what would be the most idiomatic and resilient approach to realize this behavior?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions