Wulff, Oliver wrote: > I'm a little bit confused. > > I had a look to the gzip interceptor in cxf 2.1.2. I noticed that you don't > use an "ending" interceptor anymore for the GzipOutInterceptor but for the > GzipInInterceptor. Why? > Why do you have to use an "ending" interceptor for the InInterceptor?
Dan changed the architecture of the out interceptor when he implemented it on the trunk to use a streaming approach where the main interceptor replaces the output stream with one that just has a small buffer, and when that buffer is full it automatically starts streaming the compressed data. This means it no longer requires an ending interceptor as it does the compression as it goes along rather than waiting until the end. For the in direction, the only purpose of the ending interceptor is to put the original (non-gzip) input stream back into the message after we've read the compressed data. When I first wrote the interceptor it didn't do this but then I found that it broke HTTP pipelining, i.e. the connection closed after reading the first compressed message, and the client had to establish a new connection for future requests. By putting the original stream back at the end the connection could remain open to be re-used by the client. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
