cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Why does CXF JAX-RS set content-type on GET requests with no body?
Date Thu, 13 Aug 2015 12:27:07 GMT
Hi,
We've talked a bit more about it with Aki where we indeed came to a 
shared understanding it was a workaround specifically around some 
HttpUrlConnection issues.
I've added a new property "set.content.type.for.empty.request" that (in 
case of the default conduit) can be set to false, is enabled by default 
otherwise.

I'm hoping that eventually we can have this property disabled by default 
over time. See CXF-6528.
Aki, do you have an HTTP proxy setup in your office somewhere ? May be 
you can double check if GET with custom Accept is affected or not with
"set.content.type.for.empty.request" set to false ?

Thanks, Sergey

On 11/08/15 15:02, Aki Yoshida wrote:
> Hi Sergey,
> */* may appear somewhere where the media-type is specified, but this
> value still appears to violate the BNF rules given for the
> Content-Type header.
> http://tools.ietf.org/html/rfc2045#section-5.1
>
> So, I still think it is actually wrong to set the content-type header
> with */*, no?
> regards, aki
>
> 2015-08-11 12:25 GMT+02:00 Sergey Beryozkin <sberyozkin@gmail.com>:
>> Hi Aki
>> On 11/08/15 10:14, Aki Yoshida wrote:
>>>
>>> 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.
>>> ;-)
>>>
>> Well, I'm not sure, one thing is definite is that setting a wildcard
>> Content-Type helped to solve the strange Accept replacement bug. As I said
>> even without a proxy if it empty POST then a form payload is added. I think
>> in that the case the target server had @Produces (text/xml) or json and the
>> net effect was that the runtime returned the error due to media type
>> mismatches.
>>
>> The problem is not a wildcard but the actual redundant use of Content-Type.
>> It is not an http consumer issue, ie. why Spring bother parsing Content-Type
>> for GET ?
>>>
>>> Regarding the use of value */* for the content-type header , isn't
>>> this value syntactically invalid?
>>>
>> Not at all, */* is a valid media type. The Spring error is arguable because
>> the more friendly server can assume instead that */* is equivalent to CT
>> missing and then defaulting to some type as in JAX-RS servers.
>>>
>>> There is something interesting in the following section of the MIME spec.
>>> http://tools.ietf.org/html/rfc2045#section-5.2
>>> ----
>>> 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.
>>>
>> I'm not sure we should use text/plain for GETs :-) as a workaround. */* is a
>> valid media type, though I do agree there should be a way to completely
>> block it. This is already done in case of async conduits which do not
>> exhibit strange side-effects...
>>
>> Thanks, Sergey
>>
>>
>>> regards, aki
>>>
>>>
>>>
>>> 2015-08-10 22:26 GMT+02:00 Sergey Beryozkin <sberyozkin@gmail.com>:
>>>>
>>>> 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 <sberyozkin@gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>> 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:
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cxf.547215.n5.nabble.com/Why-does-CXF-JAX-RS-set-content-type-on-GET-requests-with-no-body-tp5759908.html
>>>>>>>>
>>>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com


Mime
View raw message