You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Emil Dombagolla <do...@gmail.com> on 2011/07/01 04:34:30 UTC

Re: GZIP compression

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 [dombagolla@gmail.com]
> Sent: Thursday, June 30, 2011 5:47 AM
> To: users@cxf.apache.org
> 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 <freeman.fang@gmail.com
> >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:ffang@fusesource.com
> > Web: fusesource.com
> > Twitter: freemanfang
> > Blog: http://freemanfang.blogspot.**com <http://freemanfang.blogspot.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >