Do not propagate forwarded body Content-Type to the real response

[scottfrederick]

ProxyExchange.forward() returns HTTP 500 for any request whose client sends no Accept header on recent Tomcat versions.

Cause

ProxyExchange.forward() renders the request body through a HttpServletResponseWrapper that captures the rendered bytes so they can be replayed as the forwarded request's input.

The wrapper does not intercept Content-Type, so it delegates to the real response. The type written there is the one negotiated for the outer request. A body rendered as String for a client that sent no Accept header negotiates text/plain. That value stays on the real response when the forward is dispatched.

Historically this was harmless. Response.getHeader("Content-Type") returned null, so the forwarded handler re-negotiated and picked its own type. Tomcat changed getHeader to return the content type (https://bz.apache.org/bugzilla/show_bug.cgi?id=69967, released in 9.0.116, 10.1.53 and 11.0.19). The forwarded handler now sees Content-Type as already set, skips re-negotiation, finds no text/plain converter for its return type, and fails with HTTP 500.

Why existing tests did not catch this

postForwardBody and postForwardForgetBody are the two tests that exercise this path, and both send Accept: applicati on/json , which negotiates a type the forwarded handler can also produce, so the propagated Content-Type is one the handler can satisfy.

[spencergibb]

Only proxyexchange webmvc?