The interaction between topology-level config for the same and this new gateway-level config is an important topic. Generally, topology-level config overrides gateway-level config. This scenario should follow the same pattern.
If 404 responses cannot be handled at the topology level, then perhaps there is a distinct configuration for that case? Or, the handler could check whether the response already includes the relevant header(s), and skip adding them in those cases? As Larry suggested, there is probably a good case for gateway-level config for this, as most probably want it for the entire gateway, so having the ability to configure it for the gateway is a good addition. On Wed, Mar 19, 2025 at 11:28 AM larry mccay <lmc...@apache.org> wrote: > Hi Tamás - > > Thank you for bringing this up! > I think that configuring it at the gateway level makes sense in addition to > leaving support for topology specific behavior. > There may be consumers that only want this behavior for a single topology > in which case they could just use the webappsec provider. > > Most will probably want it for the entire gateway though. > > I would go forward with support for both to provide flexibility and > backward compatibility. > Be sure to test what happens with both configured. Not sure we want 2 > headers being added. > > thanks again! > > --larry > > On Wed, Mar 19, 2025 at 11:06 AM Tamás Hanicz <hanic...@gmail.com> wrote: > > > Hey, > > > > I've just opened a JIRA <https://issues.apache.org/jira/browse/KNOX-3111 > > > > on this subject as well. The issue is that the Strict-Transport-Security > > headers are missing for 404 responses. Currently this config is topology > > wide and set in the WebAppSec provider. To include this header for 404 it > > has to be set in jetty with a handler. However this is a global > > configuration meaning every response would contain it if enabled. This > > should be put in the gateway-site.xml file. > > > > Does anyone have any suggestions? > > > > Regards, Tamas > > >
