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
