cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Commented] (CXF-6101) Accept Header not Respected with Response from Custom MessageReader
Date Thu, 13 Nov 2014 10:32:33 GMT


Sergey Beryozkin commented on CXF-6101:

Right it is known case. What if the client who expects say text/xml and the server responds
400 with a plain text ? Should the runtime fail because Accept is not matched even though
a plain text response would be more typical for HTTP errors ? So the error responses are not
routed via the intersection with Accept. But the fact it is picking up text/xml is a bug.
it is coming from a default JAX-RS Binding by default, I'll fix it, the spec actually requires
application/octet-stream in response Content-Type is not set :-).

> Accept Header not Respected with Response from Custom MessageReader
> -------------------------------------------------------------------
>                 Key: CXF-6101
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.0.2
>            Reporter: Joseph Athman
>            Priority: Minor
> I have created a custom MessageBodyReader class which implements the readFrom method
and attempts to deserialize a JSON message using a specialized deserializer. If this fails
for some reason, I am throwing a WebApplicationException with a Response build like this:
> {{Response.status(HttpStatus.BAD_REQUEST_400).entity(myCustomResponseObject).build()}}
> On the incoming request there is an Accept header which is respected when processing
proceeds normally, but this header is not respected if I throw an exception in the readFrom
method (content type of the response is always "text/xml"). The problem seems to be in the
{{JAXRSInInterceptor}} class which creates a default message which does not have the exchange
set on it, so when the createMessage method is invoked it is unable to find the correct content
type so it will always default to "text/xml". Contrast the way this method works with how
the {{ServiceInvokerInterceptor}} class creates a new message, it sets the exchange on the
new message first before creating it.
> I realize I could set an explicit media type when creating the response but this seems
to defeat the purpose of server side content negotiation. 

This message was sent by Atlassian JIRA

View raw message