cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: Why does CXF JAX-RS set content-type on GET requests with no body?
Date Tue, 11 Aug 2015 09:14:26 GMT
HI Sergey,
it could be that the problem had something to do with the proxy's
configuration and not really a bug? Not related to this content-type
issue, we had a similar misconfiguration in the forwarding rule (e.g.,
it was letting only "Upgrade" accepted but not "upgrade") that
prevented some clients e.g., IE from opening a websocket through it.

Regarding the use of value */* for the content-type header , isn't
this value syntactically invalid?

There is something interesting in the following section of the MIME spec.
Default RFC 822 messages without a MIME Content-Type header are taken
   by this protocol to be plain text in the US-ASCII character set,
   which can be explicitly specified as:

     Content-type: text/plain; charset=us-ascii

This default is assumed if no Content-Type header field is specified.
   It is also recommend that this default be assumed when a
   syntactically invalid Content-Type header field is encountered.

That means, we could also use "Content-type: text/plain;
charset=us-ascii" instead of the no content-type to have the same
effect or overwrite the default value with some valid content type.
Interestingly, the last sentence recommends the server to accept a
syntactically invalid type like */* and assume the default text/plain
ascii type. But it is only recommended and not required.

regards, aki

2015-08-10 22:26 GMT+02:00 Sergey Beryozkin <>:
> On 10/08/15 21:23, Sergey Beryozkin wrote:
>> 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.
> and wildcard is set to bypass that proxy bug, because it is just a neutral
> value.
> Sergey
>> 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