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
