axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stadelmann Josef" <>
Subject AW: Axis2c and deflate_module
Date Tue, 15 Nov 2011 08:24:57 GMT
In this case I feel  MTOM is oversold as it stands. 
Where is the optimization making things smaller not larger?
Given we can compress a content and make it an attachment 
it might be worth to look for SwA (SOAP with Attachments).
Or does somebody more knowledge to the basic subject have 
a better idea? I like to learn as well.

-----Urspr√ľngliche Nachricht-----
Von: Andreas Veithen [] 
Gesendet: Donnerstag, 10. November 2011 19:35
An: Apache AXIS C User List
Betreff: Re: Axis2c and deflate_module

On Thu, Nov 10, 2011 at 15:07, Stadelmann Josef
<> wrote:
> Doing zip and unzip in the proper order is definitely a job for MTOM.
> How shall axis2 or one of its message receiver know where the zipped section
> in a stream of bytes starts/ends? Axis for sure has no clue about that. But
> MTOM has.

That is not correct. MTOM is based on MIME, more precisely on the part
that describes MIME multipart messages. MIME only supports
Content-Transfer-Encoding (base64, binary, quoted-printable, etc.),
but not Content-Encoding. HTTP on the other hand supports
Content-Encoding (e.g. gzip) and Transfer-Encoding (e.g. chunked).
That means that MTOM doesn't handle compression. Compression can only
be handled in two places in the stack: at the transport level (HTTP)
or in the application (service implementation). It is not MTOM's


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message