Add HttpHeaders argument resolver for HTTP service

[quaff]

No description provided.

[bclozel]

Thanks for reaching out, but we'd like to discuss first this enhancement proposal.
Similar to #34227, I'm not sure why we should consider this use case for HTTP interfaces.

We already support @RequestHeader for a single header, or Map/MultivalueMap for many headers. The goal of HTTP interface services is to provide a Java interface for developers with a meaningful API. We don't want to turn this feature into another way to call HTTP clients.

Here, I don't see what HttpHeaders would bring here, besides getting/setting transport-specific headers or copying entire headers from another call. Both these use cases are wrong in my opinion.

[quaff]

Here, I don't see what HttpHeaders would bring here, besides getting/setting transport-specific headers or copying entire headers from another call. Both these use cases are wrong in my opinion.

I agree it's a bit redundant, but I think the semantic is more accurate compare to @RequestHeader MultiValueMap<String, ?>, IMO most developers may expect HttpHeaders is resolved as well as HttpMethod.

[bclozel]

I think that this would confuse developers, since HttpHeaders contains the entire set of headers to be sent, including "Content-Length", "Content-Type" and more. This begs the question: which headers should be sent as-is or overwritten by the client on the way out?

Thanks for the proposal, but I'm declining this enhancement.

[quaff]

I think that this would confuse developers, since HttpHeaders contains the entire set of headers to be sent, including "Content-Length", "Content-Type" and more.

@RequestHeader MultiValueMap<String, ?> may contains those headers also.

This begs the question: which headers should be sent as-is or overwritten by the client on the way out?

Agree.