[
https://issues.apache.org/jira/browse/CXF-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Roberts updated CXF-1276:
-----------------------------
I've looked at your change on the trunk and I don't think it'll fix it for me.
The fix in rev 609658 means that it will now try and parse a charset out of the
content-type first. However if there is no charset in the content-type (which
there isn't in my case, using MTOM) it still tries to use
connection.getContentEncoding(), which will never be a valid charset - it's
either null or something like "gzip" or "deflate".
> Content-Encoding treated as a charset by
> HTTPConduit.WrappedOutputStream.handleResponse
> ---------------------------------------------------------------------------------------
>
> Key: CXF-1276
> URL: https://issues.apache.org/jira/browse/CXF-1276
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.0.3, 2.0.4
> Reporter: Ian Roberts
> Assignee: Daniel Kulp
> Fix For: 2.0.4
>
>
> HTTPConduit.WrappedOutputStream.handleResponse (HTTPConduit.java, around line
> 1920):
> ---------
> String enc = connection.getContentEncoding();
> if (enc == null
> && ct != null
> && ct.indexOf("charset") != -1) {
> enc = ct.substring(ct.indexOf("charset") + 8);
> if (enc.indexOf(";") != -1) {
> enc = enc.substring(0, enc.indexOf(";"));
> }
> }
> inMessage.put(Message.ENCODING, HttpHeaderHelper.mapCharset(enc));
> ---------
> When the HTTP response has a valid Content-Encoding header (e.g.
> "Content-Encoding: gzip"), this fails as it tries to treat "gzip" as a
> charset name. On 2.0.3 I get:
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:846)
> at
> org.apache.cxf.helpers.HttpHeaderHelper.mapCharset(HttpHeaderHelper.java:82)
> This has been fixed (CXF-1227) in the latest 2.0.4 snapshot and in that I get:
> java.io.IOException: Invalid character set gzip in request.
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1936)
> I haven't tried it in the 2.1 snapshot but the trunk version of HTTPConduit
> has the same code as the 2.0.4 branch.
> Replacing String enc = connection.getContentEncoding(); with String enc =
> null; is enough to make it work but I don't know if there's a better way to
> fix it.
> The background to this is that I'm working with a web service that does GZIP
> compression and I've written a pair of interceptors to GZIP the request
> stream and unzip the response, based on the code in
> samples/configuration_interceptor but doing the Content-Encoding headers
> properly (i.e. adding one to the request, and checking for one in the
> response before unzipping). I'm more than happy to contribute these to CXF
> but they currently only work with the fix I described above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
