You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Ian Roberts (JIRA)" <ji...@apache.org> on 2007/12/10 14:16:43 UTC
[jira] Created: (CXF-1276) Content-Encoding treated as a charset by
HTTPConduit.WrappedOutputStream.handleResponse
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
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.
[jira] Updated: (CXF-1276) Content-Encoding treated as a charset by
HTTPConduit.WrappedOutputStream.handleResponse
Posted by "Ian Roberts (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (CXF-1276) Content-Encoding treated as a charset
by HTTPConduit.WrappedOutputStream.handleResponse
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-1276.
------------------------------
Resolution: Fixed
Fix Version/s: 2.0.4
I think this is now resolved on trunk. I'll merge it to 2.0.4 shortly.
> 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.
[jira] Assigned: (CXF-1276) Content-Encoding treated as a charset
by HTTPConduit.WrappedOutputStream.handleResponse
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp reassigned CXF-1276:
--------------------------------
Assignee: Daniel Kulp
> 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
>
> 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.