You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Glen Mazza (JIRA)" <ji...@apache.org> on 2012/10/16 15:59:03 UTC

[jira] [Created] (CXF-4572) GZIPOutInterceptor not negotiating first without compressing

Glen Mazza created CXF-4572:
-------------------------------

             Summary: 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

[jira] [Commented] (CXF-4572) GZIPOutInterceptor not negotiating first without compressing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477025#comment-13477025 ] 

Sergey Beryozkin commented on CXF-4572:
---------------------------------------

+1 to adding 'force'
                
> 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

[jira] [Commented] (CXF-4572) GZIPOutInterceptor not negotiating first without compressing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477019#comment-13477019 ] 

Sergey Beryozkin commented on CXF-4572:
---------------------------------------

This will also affect JAX-RS proxies.
The question is, if some payload is submitted with POST, how do we know if the intention is not to actually gzip the outgoing payload ?
Should we introduce a contextual property so that GZIP can also affect the original outgoing payload ?


                
> 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

[jira] [Commented] (CXF-4572) GZIPOutInterceptor not negotiating first without compressing

Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
    [ 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

[jira] [Commented] (CXF-4572) GZIPOutInterceptor not negotiating first without compressing

Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477022#comment-13477022 ] 

Glen Mazza commented on CXF-4572:
---------------------------------

Perhaps we can put in a "force" attribute similar to the FI interceptor that JAX-RS can use by default while allowing the negotiation to still occur with JAX-WS.
                
> 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

[jira] [Resolved] (CXF-4572) GZIPOutInterceptor not negotiating first without compressing

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-4572.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.7.1
                   2.6.4
         Assignee: Daniel Kulp
    
> 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
>            Assignee: Daniel Kulp
>            Priority: Minor
>             Fix For: 2.6.4, 2.7.1
>
>
> 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