cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Kane (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CXF-5656) ContentType is removed for InternalServerError and doesn't seem to be a way to set a charset
Date Thu, 27 Mar 2014 12:16:19 GMT
Andy Kane created CXF-5656:
------------------------------

             Summary: ContentType is removed for InternalServerError and doesn't seem to be
a way to set a charset
                 Key: CXF-5656
                 URL: https://issues.apache.org/jira/browse/CXF-5656
             Project: CXF
          Issue Type: Bug
          Components: JAX-RS
    Affects Versions: 2.7.10, 2.7.7
            Reporter: Andy Kane


We have a Rest service that uses JAX-RS and CXF.  When we used CXF 2.3.3, if there was a problem
with the request and a non 200 status code was returned, the browser would display the message
from the response with any encoded non ASCII characters as the ContentType returned application/json;charset=utf-8.
 

After upgrading to 2.7.7, we noticed that non ASCII characters where not being encoded for
Status 500 - Internal Server Error.  This doesn't happen for any other status codes and we
noticed that charset=utf-8 was being stripped from the ContentType.  After looking through
the CXF code, I noticed that the AbstractHTTPDestination class was removing the ContentType
(line 553).  The ContentType was then re-added in getContentTypeFromMessage method in the
headers object without the Charset.  Looking at this method, I noticed that the encoding was
taken from Message.ENCODING and in our case this was null.  

There doesn't seem to be a way of setting org.apache.cxf.message.Message.ENCODING from either
the ExceptionMapper or ExceptionMapper.  I have also set the encoding type in the Response
object in ExceptionMapper, but this doesn't seem to make much difference either. 

Removing the ContentType seems like a bug, as if the ContentType has been previously set and
then this should be preserved.  Is there a work around for this problem in the mean time.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message