Parameters defined via `@ClientHeaderParam` don't get applied to outbound request

Hi everybody,

when using @RegisterClientHeaders along with DefaultClientHeadersFactoryImpl I expected the factory to behave like it’s described in the specification under Specifying Additional Client Headers

This interface has a single method and takes two read-only MultivaluedMap parameters … The method should return a MultivaluedMap that contains the headers to merge with this second map for the “final” map of headers to be sent to the outbound processing flow.

Now, when I check the respective code the second parameter clientOutgoingHeaders is actually not used (except for logging) and thus not merged to the output MultivaluedMap:

    @Override
    public MultivaluedMap<String, String> update(MultivaluedMap<String, String> incomingHeaders,
                                                 MultivaluedMap<String, String> clientOutgoingHeaders) {

        if (LOG.isLoggable(Level.FINER)) {
            LOG.entering(CLASS_NAME, "update", new Object[]{incomingHeaders, clientOutgoingHeaders});
        }
        MultivaluedMap<String, String> propagatedHeaders = new MultivaluedHashMap<>();
        Optional<String> propagateHeaderString = getHeadersProperty();
        if (propagateHeaderString.isPresent()) {
            Arrays.stream(propagateHeaderString.get().split(","))
                  .forEach( header -> {
                      if (incomingHeaders.containsKey(header)) {
                          propagatedHeaders.put(header, incomingHeaders.get(header));
                      }
                  });
        }
        if (LOG.isLoggable(Level.FINER)) {
            LOG.exiting(CLASS_NAME, "update", propagatedHeaders);
        }
        return propagatedHeaders;
    }

Thus, none of the header-values configured i.e. via @ClientHeaderParam get merged to the outbound request.

Is this behavior of DefaultClientHeadersFactoryImpl intended (since one can register its own Factory it’s actually easy work around … but still is surprising)?

Regards

[kenfinnigan]

I actually just hit this myself and was going to raise an issue.

@andymc12 do you agree that nothing in the spec says it should behave this way?

Will look to provide a fix in the morning, as this should be done for 2.0 in MP 4.0

[kenfinnigan]

I’ve actually just submitted a PR to RESTEasy to perform the merge if the DefaultClientHeadersFactoryImpl is used.

It’s definitely something we can look into post 2.0, we’d need to decide whether it makes sense to favor clientOutgoingHeaders or output of update().