I would just say that once you configure in the GZIP interceptors and such, you are kind of outside the SOAP/JMS spec. By default, the GZIP stuff is negotiated anyway. If a non-CXF SOAP/JMS client sends a message, it wouldn't have the Accept-Transfer-Encoding thing and thus the server would just respond back in the normal non-gzip form anyway. Completely compliant.
Dan On Tuesday 07 December 2010 8:24:00 am Freeman Fang wrote: > Hi Willem, > > Actually what my real concer is the chapter 2.4 in the spec > 2.4 The JMS Message Body > The contents of the JMS Message body MUST be the SOAP payload as a JMS > BytesMessage or TextMessage. † [Definition: A fault MUST be generated > with subcode unsupportedJMSMessageFormat when the arriving message > format is not BytesMessage or TextMessage. † ] > > The bytes or characters of the JMS Message payload correspond to the > MIME format as indicated by the definition of the contentType > property. In this way, the SOAP node determines the proper formatting > of the SOAP payload irrespective of the underlying JMS message type, > and specifies an appropriate value for the contentType property which > describes it to the receiving SOAP node. Specifically, if the payload > is formatted as a MIME multipart message, then the first byte or > character encountered in the JMS Message body MUST be the start of the > MIME boundary for the start of the first part — what MIME Part One > [IETF RFC 2045] section 2.5 calls a "Body Part". † If the message is > formatted as "text/xml" or "application/soap+xml", then the first byte > or character of the JMS Message body MUST be the start of a conforming > XML document. † > > > > Regards > > Freeman > > On 2010-12-7, at 下午9:13, Willem Jiang wrote: > > Hi Freeman, > > > > I think as there is no Content-Encoding/Accept-Encoding "JMS Message > > Properties" defined in the specs, we are safe to extends the gzip > > support in soap over jms. > > > > If the server doesn't support the gzip encoding, CXF client can > > adjust itself, as this extension is not in the spec. > > > > Just my 2 cents. > > > > On 12/7/10 7:30 PM, Freeman Fang wrote: > >> Hi, > >> > >> Recently with [1]CXF-3146, I make an improvement to let gzip encoding > >> works over jms transport, but it's only applicable with cxf 2.2 > >> branch, > >> as the jms transport with cxf 2.2 is a kind of proprietary > >> implementation. > >> Since cxf 2.3, cxf implements the soap over jms spec[2] which ensure > >> interoperability between the implementations of different Web > >> services > >> vendors. With this spec, seems there's noway we can enable gzip > >> encoding > >> over jms. I previously thought the main barrier is there's no > >> Content-Encoding/Accept-Encoding "JMS Message Properties" defined > >> in the > >> specs, but "JMS Message Properties" in the spec isn't exclusive so > >> that > >> seems we could have extend it to make at least both cxf client/server > >> over jms understand gzip encoding. But finally I realize that the > >> below > >> part in the spec is the real reason we can't use gzip encoding. > >> > >> 2.4 The JMS Message Body > >> > >> The contents of the JMS Message body MUST be the SOAP payload as a > >> JMS > >> BytesMessage or TextMessage. † [Definition: A fault MUST be > >> generated > >> with subcode unsupportedJMSMessageFormat when the arriving message > >> format is not BytesMessage or TextMessage. † ] > >> > >> The bytes or characters of the JMS Message payload correspond to the > >> MIME format as indicated by the definition of the contentType > >> property. > >> In this way, the SOAP node determines the proper formatting of the > >> SOAP > >> payload irrespective of the underlying JMS message type, and > >> specifies > >> an appropriate value for the contentType property which describes > >> it to > >> the receiving SOAP node. Specifically, if the payload is formatted > >> as a > >> MIME multipart message, then the first byte or character > >> encountered in > >> the JMS Message body MUST be the start of the MIME boundary for the > >> start of the first part — what MIME Part One [IETF RFC 2045] > >> section 2.5 > >> calls a "Body Part". † If the message is formatted as "text/xml" or > >> "application/soap+xml", then the first byte or character of the JMS > >> Message body MUST be the start of a conforming XML document. † > >> > >> > >> > >> Is my understanding correct? Or is there any way we can implement the > >> gzip encoding without breaking the spec? > >> > >> Any comment is welcome. > >> > >> [1]https://issues.apache.org/jira/browse/CXF-3146 > >> [2]http://www.w3.org/TR/soapjms/ > >> > >> Thanks > >> > >> Freeman -- Daniel Kulp [email protected] http://dankulp.com/blog
