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. 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. 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/
