Closed j-denner closed 1 month ago
I phrase it the other way round. There is the invariant propagated=true => field != null
that is currently not enforced in any location. Such a check could be added, but then it should be introduce in all places that accept HttpHeader
as a configuration. Since HttpHeader is an interface consumers may have derived classes that do no fulfill this contract.
The code has probably little affect.
I think no. When field is null, the retrieved header value is ignored. So the early filtering reduces work - like for fields
.
I don't known how many breaking changes you 'dare' with the next major release. The HttpHeader interface could be changed to a sealed one, that allows the current Enum and a new HttpHeaderRecord record class. The latter can enforce the contract and consumers can still create own Headers. Just some thoughts.
For the next major release, I am thinking of moving the HttpHeader interface from the core module to the servlet module. This would already be a breaking change. Implementing your suggestion would be an additional and possible option.
AddHttpHeaderToLogContextFilter: Filter immediately for getField presence