Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

int-http:inbound-gateway do not sets content-type header [INT-3697] #7657

spring-operator opened this issue Apr 10, 2015 · 5 comments


Copy link

spring-operator commented Apr 10, 2015

Alexei Osipov opened INT-3697 and commented

Almost same issue as in #7474.

Default behavior of int-http:inbound-gateway does not recognizes integration header "contentType" and tries to look up "Content-type".

So DefaultHttpHeaderMapper.inboundMapper().fromHeaders(...) just skips MessageHeaders.CONTENT_TYPE header.

Affects: 4.1.2, 4.1.3

Referenced from: pull request #1419

Copy link
Contributor Author

Alexei Osipov commented

Test case:

    public void testFromHeaders() {
        Map<String, Object> map = new HashMap<>();
        map.put(MessageHeaders.CONTENT_TYPE, "abc");
        MessageHeaders messageHeaders = new MessageHeaders(map);
        HttpHeaders httpHeaders = new HttpHeaders();
        DefaultHttpHeaderMapper.inboundMapper().fromHeaders(messageHeaders, httpHeaders);

Copy link
Contributor Author

Artem Bilan commented


DefaultHttpHeaderMapper.inboundMapper() is for inbound HTTP Requests, so it isn't intended to get deal with non-standard HTTP headers.

If you mean the response part, then we rely there on the Accept request HTTP header.
And there is a code on the matter:

if (CollectionUtils.isEmpty(acceptTypes)) {
	acceptTypes = Collections.singletonList(MediaType.ALL);
for (HttpMessageConverter converter : this.getMessageConverters()) {
	for (MediaType acceptType : acceptTypes) {
		if (converter.canWrite(content.getClass(), acceptType)) {
			converter.write(content, acceptType, response);

Where the appropriate HttpMessageConverter populates correct Content-Type response header.

Please, share your specific case, where you really need the contentType from integration flow and when HttpMessageConverter logic isn't fit for you.

Thank you!

Copy link
Contributor Author

Alexei Osipov commented

Yes, I mean processing of response for an inbound HTTP request.

We use a pair of int-http:inbound-gateway and int-http:outbound-gateway to proxy incoming requests to an external system. So we want to transfer a Content-Type from a reply of external service as is to a requesting service.


  1. request comes to inbound-gateway
  2. inbound-gateway converts headers with DefaultHttpHeaderMapper#toHeaders(...) (Content-Type -> contentType)
  3. outbound-gateway converts headers back with DefaultHttpHeaderMapper#fromHeaders(...) (contentType -> Content-Type)
  4. outbound-gateway sends HTTP request to external service
  5. external service processes request and generates response
  6. outbound-gateway gets HTTP response from external service
  7. outbound-gateway converts response headers with DefaultHttpHeaderMapper#toHeaders(...) (Content-Type -> contentType)
  8. inbound-gateway converts response headers with DefaultHttpHeaderMapper#fromHeaders(...) (Expected: contentType -> Content-Type. Actual: header is lost)
  9. inbound-gateway sends response to client

I agree that it's not really common case but the actual behavior is quite confusing for me.

Copy link
Contributor Author

Gary Russell commented

Merged to master.

Alexei_Osipov Unfortunately, we can't apply this change to the 4.1.x branch because it represents a behavior change. Although it's a bug, we can't afford the potential breakage of applications that expect the existing behavior.

With 4.2, we will be able to cover the behavior change in the 4.1 to 4.2 migration guide.

For 4.1, the work-around is to add a <header-enricher/> to copy the header as content-type.

Copy link
Contributor Author

Alexei Osipov commented

Artem, Gary, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants