Re: [soapui-user] Feature Proposal: HTTP Compression Selection

[<mm...@nc...>]

I have implemented HTTP Compression as proposed in feature request
http://sourceforge.net/tracker/index.php?func=detail&aid=1947545&group_id=136013&atid=737766.
 Compression is optional and can be enabled for requests, responses, or
both.  Either GZIP or DEFLATE can be selected as the compression
algorithm.  The server where your SOAP requests are sent must be able to
handle the request compression algorithm you choose.  The server I test
with, WebSphere 6.1,  seems to handle both algorithms natively.  The
settings were added to the existing HTTP settings dialog box and so effect
communications for all SOAP end-points as well as WSDL imports.  A follow
up feature enhancement would be to allow end-point configurations that
override the global HTTP settings so compression could be targeted only to
certain end-points if desired.

The attached ZIP file contains a description of the patch (basically what
I have said here), a list of files that have changed, and the .patch file
itself.  It is based on the released 2.0.2 code base since the latest code
is not available in the SourceForge repository.

Developing unit tests for this functionality is the next step and most of
the work would be getting the local Jetty unit testing server to handle
compression.  Because of the complexities of that, I didn’t have time to
do that in this patch but a follow up patch will implement the automated
unit testing of this feature.

Review of this patch is welcome at this time and I would love any feedback
you have.

-Mark


> As mentioned in my previous email to this list, I am proposing a couple of
> features/modifications to soapUI and this is the second feature
> discussion.
>
> soapUI already handles the processing of compressed web service responses
> but only seems to process GZIP compressions.  There are other compression
> algorithms that have been commonly used over the years with HTTP, such as
> DEFLATE (free of any patents or copyrights and currently built into Java).
>  I am going to suggest that DEFLATE compressed response streams be handled
> with soapUI and to also add the ability to configure the HTTP settings in
> the application and to specify a list of compression algorithms.  This
> avoids have to set a custom header on the request which is how you must do
> this with soapUI today.  I will be attempting to make this change to over
> the next week.  How useful will this feature be for those of you wanting
> to test with compression?
>
>