[
https://issues.apache.org/jira/browse/CXF-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477921#comment-13477921
]
Glen Mazza commented on CXF-4572:
---------------------------------
A simple test case can be made by taking the Double It tutorial[1], replacing
two classes with those here[2], and then running mvn clean install
tomcat:redeploy to deploy the server and mvn exec:exec from the client
subdirectory to activate the SOAP client. Wireshark will show the results.
[1] https://github.com/gmazza/blog-samples/tree/master/web_service_tutorial
[2]
https://github.com/gmazza/blog-samples/tree/master/compressing_soap_messages/cxf-gzip
> GZIPOutInterceptor not negotiating first without compressing
> ------------------------------------------------------------
>
> Key: CXF-4572
> URL: https://issues.apache.org/jira/browse/CXF-4572
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 2.7.0
> Reporter: Glen Mazza
> Priority: Minor
>
> The GZIPOutInterceptor, like the Fast Infoset out interceptor, is supposed to
> negotiate first with the server prior to sending a compressed message as
> stated in the docs
> (http://cxf.apache.org/docs/annotations.html#Annotations-GZIP). I.e. the
> first SOAP request, while containing the "Accept-Encoding: gzip" HTTP header,
> should still be uncompressed (only subsequent calls compressed) but it is
> still compressing the message with the first soap request. This results in
> servers not configured for GZIP to raise can't parse errors.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
