Hi Sergey, thanks. Yes we have a proxy. I'll check it against our proxy tomorrow. regards, aki
2015-08-13 14:27 GMT+02:00 Sergey Beryozkin <[email protected]>: > 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 <[email protected]>: >>> >>> 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 <[email protected]>: >>>>> >>>>> >>>>> 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 <[email protected]>: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 > >
