Hi, I am afraid your response isn't compressed, because GZIPInInterceptor decompresses response only if response Content-Encoding="gzip" or "x-gzip". The best way to check it is configure TCP monitor between your service and client and check the response entity body.
Regards, Andrei. > -----Original Message----- > From: membersound2 [mailto:[email protected]] > Sent: Dienstag, 11. November 2014 17:24 > To: [email protected] > Subject: RE: How to properly use HTTP compression with CXF 3? > > Yes of course the InInterceptor must be added to bus.getInInterceptors(). > That was just a type, sorry. > > I now found out that the webservice does not support compressed requests, but > can responst compressed. > So removing the outInterceptor returns valid xml responses. > > Though, question: how can I know from the cxf logs of my client application > that the received xml response was actually received compressed with gzip?? > > Request: > /Headers: {Accept=[text/xml], Accept-Encoding=[gzip,deflate],/ > > Response: > /Headers: {content-type=[text/xml;charset=utf-8], Date=[Tue, 11 Nov 2014 > 16:19:49 GMT], Server=[Apache-Coyote/1.1], transfer-encoding=[chunked], > Vary=[Accept-Encoding]}/ > > The response does not show anything like "content-type=gzip". But I believe > this > is due to the nature of cxf phases that the logging takes place after > decompression. > > So, how can I ensure I reveived the webservice response compressed? > > > > -- > View this message in context: http://cxf.547215.n5.nabble.com/How-to- > properly-use-HTTP-compression-with-CXF-3-tp5750949p5750990.html > Sent from the cxf-user mailing list archive at Nabble.com.
