cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
Date Wed, 08 Dec 2010 02:52:29 GMT
Hi Dan,

Thanks for your input.
And Peter Easton, who is from Soap over JMS spec group told me the new  
version spec including this proposal should be released soon, I just  
create CXF-3174[1] to track this issue and when the new version spec  
released, I'll add implementation accordingly.



On 2010-12-8, at 上午10:25, Daniel Kulp wrote:

> On Tuesday 07 December 2010 9:14:27 pm Freeman Fang wrote:
>> Hi Dan & Christian,
>> Thanks for your comment, and it's true that the jms providers like
>> Tibco EMS and Activemq allow compress messages a transport level.
>> The problem is that the SOAP over JMS spec currently doesn't support
>> the behavior for encoded(like gzip) message.
>> Fortunately,  there's same discussion on
>> maillinglist  recently[1], and the new proposal seems can resolve our
>> encoding issue, more importantly in the new proposal is that
>> ===> Change to section 2.4:
>> Replace "The bytes or characters of the JMS Message payload  
>> correspond
>> to the MIME format as indicated by the definition of the contentType
>> property" with:
>> "After being decoded according to the contentEncoding property, the
>> bytes or characters of the JMS Message payload correspond to the MIME
>> format as indicated by the definition of the contentType property"
>> Here a new contentEncoding property is introduced, moreover, it
>> specify the behavior that we can "decode according to the
>> contentEncoding property", which is exactly what we want IMO.
> That's cool.   Great timing actually as that does indeed do exactly  
> what we
> need.
>> Previously our gzip encoding over http/jms actually use two
>> properties,  Content-Encoding and Accept-Encoding,
> And that's because that is exactly what the HTTP spec calls for  
> using in this
> case.
>> the behavior on
>> server side is that check the Content-Encoding for incoming message
>> first to know if we need decode gzip, and check Accept-Encoding to  
>> see
>> if we can do gzip encoding for outgoing message(as Dan already
>> mentioned).
>> As now the new proposal only have contentEncoding property(but no
>> Accept-Encoding), how about we change the behavior on server side a
>> little bit, only check the Content-Encoding, if it's gzip encoding,
>> then we also do gzip encoding for outgoing message, that's said, if a
>> client sent out the gzip encoding message, it means client can  
>> receive
>> a gzip encoding message also.
> As long as we also still check for the Accept-Encoding as well.    
> Basically,
> if Content-Encoding is gzip and  Accept-Encoding is not specified  
> (the JMS
> case), then go ahead and do gzip.   If  Accept-Encoding is gzip,  
> then go ahead
> and gzip.   Thus, a client can send a non-gzip message but with the  
> Accept-
> Encoding set and get the gzip back.
> Dan
>> [1]
>> Thanks
>> Freeman
> -- 
> Daniel Kulp

Freeman Fang


Apache Servicemix:
Apache Cxf:
Apache Karaf:
Apache Felix:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message