[ 
https://issues.apache.org/jira/browse/CXF-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209567#comment-14209567
 ] 

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: https://issues.apache.org/jira/browse/CXF-6101
>             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
(v6.3.4#6332)

Reply via email to