Previously, it was not ideal for Spring Security to proactively set HTTP Headers because setting a header meant there was no way for the user to remove a header.
This has changed in Servlet 6.1 where the Javadoc of HttpServletResponse.setHeader(String, String) states:
Passing null as the value removes all headers with the given name.
Users could always override the default headers with a new value. Since servlet 6.1, they can now remove the header.
Spring Security should be updated to set the headers eagerly by default. Users wishing to override headers can now do so.
This does break passivity because today applications that set or adds a single cache control header ensures that Spring Security sets no cache control headers.
- Applications cannot use addHeader if they want to override Spring Security's default headers
- Applications must explicitly override every cache control header that they wish to change
Previously, it was not ideal for Spring Security to proactively set HTTP Headers because setting a header meant there was no way for the user to remove a header.
This has changed in Servlet 6.1 where the Javadoc of
HttpServletResponse.setHeader(String, String)states:Users could always override the default headers with a new value. Since servlet 6.1, they can now remove the header.
Spring Security should be updated to set the headers eagerly by default. Users wishing to override headers can now do so.
This does break passivity because today applications that set or adds a single cache control header ensures that Spring Security sets no cache control headers.