11. SetCompressionto enable or disable the negotiation of GZIP compression.

Important is the word "negotiation" here.

If you are using a browser to access a DataPower service, then your browser and DataPower do the negotiation for you.
Nothing needs to be done by you.

So what if using "curl" to access a DataPower service?

From "curl" manpage:

--compressed
(HTTP) Request a compressed response using one of the algorithms
libcurl supports, and return the uncompressed document. If this
option is used and the server sends an unsupported encoding,
curl will report an error.

You can check whether "your curl" does support gzip compression by executing "curl -V".

If you find "libz" amount the "Features" then it can.

Again, "--compressed" does a negotiation, no guarantee that both sides (curl/DataPower) will agree on compression.

So how can you "see" whether compression was used?

Yes, a packet capture will allow you to see this.
But there is a simpler method, use "curl -v" (for "verbose" output).
If the HTTP response from DataPower contain "Content-Encoding: gzip" header entry, then response was returned compressed.

I just turned Compression on on coproc2 service FSH and did send ab.xml (<a>1<b>2</b>3</a>) with double.xsl stylesheet:

Now that file data should be store in a database via <dp:url-open ...>, but not in UTF-8 but its original encoding.
While there is a solution for this kind of problem (slides 6-8 in this WSTE webcast)the conversion to and from UTF-8 are overhead at least.

In addition the filename of the file uploaded is not available by DataPower convert-http action.

One solution is making use of swaform tool which even is able to deal with binary file data in file upload fields (see slide 16 of this WSTE webcast).

on developerWorks DataPower Forum I looked into the code and did some experiments.

While you cannot prevent "Connection" header from being returned to a client it depends whether you can for "X-Backside-Transport" and "Transfer-Encoding".Please see the forum posting for the details.

What I learned from that is the intention for always sending X-BacksideTransport header to a client for a WSP or MPGW.It helps to disambiguate transport failures from generated soap faults and enables guaranteed delivery protocols.