[ https://issues.jboss.org/browse/WFWIP-270?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFWIP-270: ---------------------------------------- We may change the definition slightly in the analysis. If we want we can identify some headers which we will prevent from being defined, 'Connection' and 'Date' are two candidates for this list. The implementation of path based headers relies on being early in the handler chain, as a request is received we get in there immediately and set the configured headers. The headers are the first thing written in any HTTP response, once the request is processed by it's target handler there is always the possibility it will cause the response to start to be written (headers first) - if this happens we loose the opportunity to retrospectively set any headers so we can not set our headers after processing is complete as that can be too late. A further complication is how individual handlers are implemented, if after our handler is called the target handler just calls put with a header the value set by the handler will replace the value we previously set. Undertow does not provide us a way to protect against that. However some handlers will check if a header has already been set before setting one itself, that is the case for the two examples here which is why the configuration is overriding. It is impossible for us to come up with a complete list of headers that will only be set if not already set as the deployed contexts are dynamic so we don't know how the other contexts could implement their header handling, additionally it will be very hard to prevent subsequent changes to those handlers. I think if we add some validation that prevents 'Connection' and 'Date' being set it would leave us with something that can be expanded in the future. In other cases we will just make sure it is clear that this non-override statement is not guaranteed as it will depend on the individual endpoint. -- This message was sent by Atlassian Jira (v7.13.8#713008)