Thank you so much enlighten me.thanks for you support. emil
14.11 Content-Encoding > ... > "If the content-coding of an entity in a request message is not acceptable > to the origin server, the server SHOULD respond with a status code of 415 > (Unsupported Media Type). " > > > ________________________________________ > From: Emil Dombagolla [[email protected]] > Sent: Thursday, June 30, 2011 5:47 AM > To: [email protected] > Subject: Re: GZIP compression > > hi, > > Thank you so much , providing me a solution soon ,as i need to fix this in > our production environment. > > I will choose 1st option, that way it is easier. > > but as i know http1.1 request cannot be compressed but only the response. > > in this case request also being compressed before it sends to server. that > s > the problem. > > thank you again. > Emil > > > On Thu, Jun 30, 2011 at 3:44 PM, Freeman Fang <[email protected] > >wrote: > > > Hi, > > > > Do you mean the server can only return gzip compressed response but can't > > accept gzip compressed request? This is a little bit wired as generally > the > > GZIP mode works in negotiation way. > > > > Anyway, I think you have 2 options to achieve your requirement > > > > 1. the simplest one, just specify a very large threshold(int java type) > > for the GZIPFeature which your client request message will never reach, > this > > ensure the request message isn't gzip compressed but still have the > proper > > http "Accept-Encoding" header. > > Something like > > <bean class="org.apache.cxf.**transport.http.gzip.**GZIPFeature"> > > <property name="threshold"> > > <value>a_large_size_your_** > > request_never_reach</value> > > </property> > > </bean> > > > > 2. don't use GZIPFeature, basically GZIPFeature will add > GZIPOutInterceptor > > and GZIPInInterceptor to your client, but from your scenario you don't > wanna > > the GZIPOutInterceptor, so you just add GZIPInInterceptor directly for > your > > client side InInterceptors. I'm not sure what's your server side and how > is > > your server side to implement the GZIP feature, but generally it should > use > > negotiation way, that said the server will check the client request http > > header to see if the "Accept-Encoding" is gzip compatible then can > determine > > response gzip compressed message or not. So you probably also need add a > > customer interceptor for your client side outInterceptors, just add http > > header like "Accept-Encoding"="gzip;q=1.0, identity; q=0.5, *;q=0" which > > ensure server side can return a gzip compressed response. > > > > > > Freeman > > > > > > On 2011-6-30, at 下午4:30, Emil Dombagolla wrote: > > > > Dear All, > >> > >> I am using org.apache.cxf.transport.http.**gzip.GZIPFeature for my soap > >> client. > >> > >> > >> So i expect only to compress responses ,not requests. > >> > >> > >> But by adding this feature requests are more than 1024byts are > compressed, > >> because of this i get 400 bad requests from the server.(i have bigger > >> sizes) > >> > >> So how can i configure not to compress requests but keeping responses > >> compressed? > >> > >> > >> Or how to avoid this size condition? > >> > >> > >> Please help me to configure this. > >> > >> Thanks > >> > >> Emil > >> > > > > ------------------------------**--------------- > > Freeman Fang > > > > FuseSource > > Email:[email protected] > > Web: fusesource.com > > Twitter: freemanfang > > Blog: http://freemanfang.blogspot.**com <http://freemanfang.blogspot.com > > > > > > > > > > > > > > > > > > > > > >
