@ronsigal @jamezp this looks good. Can it be merged?

Thank you for the contribution. We are cleaning up older PR's that seem to be stale. If you feel this is still an issue please feel free to re-open.

Hi @jamezp can I ask for a review please?

Hi @jamezp .

A by-product of this change is this weird-ish behavior:

webTarget
                    .path("/some-path")
                    .request()
                    .header(HttpHeaders.CONTENT_TYPE, "foo")
                    .post(Entity.entity("[]", "bar"), String.class);

will send Content-Type: foo. You could argue this is understandable, but I think most would think 'last wins'. Of course, that policy essentially means you can't use header(String, String) to set the Content-Type when you are submitting an Entity.

Regardless, the overall change is a little problematic for us as it's a behavioral change that could break our customers. We're still debating what we want to do. Move forward or try to bring back old behavior. The current front-runner is to use a ClientResponseFilter to use the request context's media type to reset the Content-Type header.

@crankydillo Let me think about this. That example seems explicit to me that the user would want to set the Content-Type header. However, the entity value should win IMO. It does seem like we should file an issue for this.

I went ahead and wrote it up here, primarily so we'll have something to track. I probably should have done that initially, but I always have to dig out my JIRA account info:P