[
https://issues.apache.org/jira/browse/KNOX-3111?focusedWorklogId=962745&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-962745
]
ASF GitHub Bot logged work on KNOX-3111:
----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Mar/25 14:04
Start Date: 20/Mar/25 14:04
Worklog Time Spent: 10m
Work Description: hanicz commented on PR #1007:
URL: https://github.com/apache/knox/pull/1007#issuecomment-2740573925
> > > How does this affect behavior when topology-level config exists for
the same?
> >
> >
> > If both are enabled and there is a request for that specific topology
the WebAppSec configuration will take precedence.
>
> Is there a test for that?
No there isn't, I validated the behaviour manually. The handler and the
StrictTransportFilter are in two different modules and are called at different
points of the requests lifecycle. What I can do is mock a response object and
call the handle and doFilter methods with it and verify after.
The setHeader method is used in the StrictTransportFilter which will
override the existing header.
Issue Time Tracking
-------------------
Worklog Id: (was: 962745)
Time Spent: 40m (was: 0.5h)
> HSTS headers are missing for 404 responses
> ------------------------------------------
>
> Key: KNOX-3111
> URL: https://issues.apache.org/jira/browse/KNOX-3111
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Affects Versions: 2.2.0
> Reporter: Tamás Hanicz
> Assignee: Tamás Hanicz
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Strict-Transport-Security header is missing for 404 responses. The
> "strict.transport.enabled" configuration is set in the WebAppSec provider
> topology wide. To include the header on 404 as well jetty has to be
> configured with a custom handler. However this is a global configuration
> which would mean every response will include this header.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
