I also have a exchangeFilter registered in the webClient which looks up attribute "x". When calling clientRequest.attribute("x") then I get a NPE.
Technically, we don't really intend null values to be stored there, as indicated by the missing @Nullable declaration in attribute(name, value) in the builder. That said, if it happens to be stored that way, we should leniently handle it.
Well, given we write typically a call to webClient.method(...) with many chained calls to the methods that build the request, it would be very annoying to break the chain to do a null check of some variable I might want to pass as an attribute.
Also, passing a null value could be a way to remove a previously set attribute.
So, I think it's best for the RequestHeadersSpec.attribute(name, value) API to be flexible.