[
https://issues.apache.org/jira/browse/CXF-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972685#comment-15972685
]
Sergey Beryozkin edited comment on CXF-7338 at 4/18/17 1:46 PM:
----------------------------------------------------------------
Providing a top-level API support for dealing with the misbehaving servers does
not sound right, and it won't work with the standard or proxy API.
The solution is to register a JAX-RS 2.0 ClientResponseFilter which will update
the response media type as needed
was (Author: sergey_beryozkin):
Providing a top-level API support for dealing with the misbehaving servers does
not sound right, and it won't work with the standard or proxy API.
The solution is to register a ClientResponseFilter which will update the
response media type as needed
> WebClient, map response Content-Type to other types
> ---------------------------------------------------
>
> Key: CXF-7338
> URL: https://issues.apache.org/jira/browse/CXF-7338
> Project: CXF
> Issue Type: Wish
> Components: JAX-RS
> Affects Versions: 3.1.9
> Reporter: Anton Johansson
> Assignee: Sergey Beryozkin
>
> I'm communicating with a third party provider and I'm using CXF (WebClient),
> like I always do. But this third party provider has messed up slightly. Even
> if the contents actually is XML, they return Content-Type
> text/html;charset=ISO-8859-1.
> So I would like the possibility to tell my client to treat text/html as
> application/xml in this specific scenario, maybe using:
> {code:java}
> client.map("text/plain", "application/xml").post(data);
> {code}
> If there's another solution or workaround that I've missed, please let me
> know!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
