cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Why does CXF JAX-RS set content-type on GET requests with no body?
Date Mon, 10 Aug 2015 20:23:29 GMT
Hi Aki

What I know is that if we have HTTP Proxy and GET without Content-Type 
then whatever Accept is there (ex. Accept: application/json) will be 
replaced with */* by HttpUrlConnection (or proxy, not sure) - I have a 
comment in the code about it though I haven't tried it myself - it was 
reported by my company's colleague.

While it is a redundant header I'd say Spring is not very HTTP friendly 
- in GET cases Content-Type simply needs to be ignored as opposed to 
reacting with the exception because it has no effect on the processing - 
the question is - would they accept GET with Content-Type 
application/json, etc :-)

I'm not saying having a wildcard Content-Type with GET is very HTTP 
friendly either :-). I'll add a property, disabled by default, but if 
enabled then drop Content-Type.

Do you have HTTP proxy somewhere nearby ? If yes, may be you can double 
check ? We can definitely have this new property (always drop CT for 
empty payloads) enabled by default eventually once the checks are green

Thanks. Sergey

On 10/08/15 18:37, Aki Yoshida wrote:
> Hi Sergey,
> If I undertand the original query, Steen is seeing "Content-Type: */*"
> in their GET request.
> In that case, I don't understand why this unnecessary header with this
> invalid type value needs to be there to avoid some side-effect that
> you mentioned.
> Did I misunderstand the situation?
> regards, aki
> 2015-08-10 16:32 GMT+02:00 Sergey Beryozkin <>:
>> There's some history related to this issue.
>> At some point I updated the CXF client code to ignore Content-Type
>> completely. Then the side-effects caused by HttpUrlConnection started
>> appearing:
>> - empty POSTs lead to HttpUrlConnection setting a form conetnt-type
>> - even more serious, if HTTP Proxy is used, a custom Accept is completely
>> lost for requests with the empty payloads.
>> So indeed, I reverted it to have Content-Type dropped in case of empty
>> payloads only if the async conduit is used.
>> I think it makes sense to let users control it via a property, as it obvious
>> that unfortunately a single solution does not work with HttpUrlConnection -
>> I'll take care of it.
>> It might also make sense to check what HttpUrlConnection does in Java 8 and
>> 9 re the above two side-effects
>> Cheers, Sergey
>> On 10/08/15 14:31, Steen Elvstrøm wrote:
>>> I've been trying to use Apache CXF JAX-RS (version 3.0.4) to send GET
>>> requests to a Spring Boot application. Unfortunately CFX adds a
>>> Content-Type: */* to the request headers which is not accepted by spring
>>> resulting in a 400 response stating "'Content-Type' cannot contain
>>> wildcard
>>> type '*'".
>>> Since a Content-Type header on a GET request doesn't really make sense
>>> when
>>> the request haven't got a request entity I guess it must be a bug.
>>> A possible workaround is to add "cxf-rt-transports-http-hc" as a
>>> dependency
>>> and setting the property "use.async.http.conduit". Is it a valid durable
>>> way
>>> to solve the issue?
>>> --
>>> View this message in context:
>>> Sent from the cxf-user mailing list archive at

Sergey Beryozkin

Talend Community Coders

View raw message