Content-Encoding treated as a charset by HTTPConduit.WrappedOutputStream.handleResponse

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.