On May 13, 2014, at 12:20 PM, Sanjeev Chopra <[email protected]> wrote:
> Hello Dan, there is no other Content* header in the request. (see http > log from SOAPUI below). Do you think this behavior is worth safeguarding > against in the Interceptor ? Yep. Just wanted to get the full header list and such to setup a decent test case for this. Thanks! Dan > > Mon May 12 23:07:25 PDT 2014:DEBUG:>> "GET > /restBaseUrl/IRestCustomerServiceBaseUrl/1.0/restservice/customer/1 > HTTP/1.1[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:>> "Content-Encoding: gzip[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:>> "Accept-Encoding: > gzip,deflate[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:>> "Host: localhost:9090[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:>> "Connection: Keep-Alive[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:>> "User-Agent: Apache-HttpClient/4.1.1 > (java 1.5)[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:>> "[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "HTTP/1.1 500 Server Error[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "Content-Type: > text/xml;charset=UTF-8[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "Transfer-Encoding: chunked[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "Server: > Jetty(7.6.8.v20121106)[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "BA[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "<ns1:XMLFault xmlns:ns1=" > http://cxf.apache.org/bindings/xformat";><ns1:faultstring xmlns:ns1=" > http://cxf.apache.org/bindings/xformat > ">java.io.EOFException</ns1:faultstring></ns1:XMLFault>" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "0[\r][\n]" > Mon May 12 23:07:25 PDT 2014:DEBUG:<< "[\r][\n]" > > > On Tue, May 13, 2014 at 8:38 AM, Daniel Kulp <[email protected]> wrote: > >> >> On May 12, 2014, at 4:02 PM, Sanjeev Chopra <[email protected]> >> wrote: >> >>> I am using GZIPInInterceptor (cxf-bundle-jaxrs-2.7.3.jar) on my >> service for >>> decompressing gzip requests coming in from clients. >>> >>> If a client sends a GET request with a 'Content-Encoding: gzip' header, >> the >>> interceptor throws an EOFException ( at >>> >> org.apache.cxf.transport.common.gzip.GZIPInInterceptor.handleMessage(GZIPInInterceptor.java:85)[151:org.apache.cxf.cxf-rt-core:2.7.3] >>> ) while trying to decompress a non-existent body in the GET request. >>> Looking at the code, the problem seems to be that >>> >> org.apache.cxf.transport.common.gzip.Message.getContent(InputStream.class) >>> returns a non-null response for a request with no body. >>> >>> Granted that it does not make sense to be sending a Content-Encoding >> header >>> in a GET request, I would expect the interceptor to tolerate this when >>> there is no "content" in the incoming request. Is this a defect ? >> >> This definitely looks like a bug in SOAP UI. :-( That certainly >> doesn’t make much sense. >> >> Can you use wireshark or similar to capture the raw request with all the >> headers and such? I’m curious to see if they are also including a >> Content-Length or Content-Type header or similar. >> >> Dan >> >> >> >>> >>> I ran into this while doing some manual testing with SOAP UI, because the >>> compression setting is at the project level. When I send a GET request >> (with >>> compression enabled in Preferences), SOAPUI includes the Content-Encoding >>> header in the request. >>> >>> Complete Stacktrace: >>> org.apache.cxf.interceptor.Fault: Could not unzip compressed message. >>> at >>> >> org.apache.cxf.transport.common.gzip.GZIPInInterceptor.handleMessage(GZIPInInterceptor.java:103)[151:org.apache.cxf.cxf-rt-core:2.7.3] >>> at >>> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)[150:org.apache.cxf.cxf-api:2.7.3] >>> at >>> >> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)[150:org.apache.cxf.cxf-api:2.7.3] >>> at >>> >> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)[167:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.3] >>> at >>> >> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)[167:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.3] >>> at >>> >> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72)[167:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.3] >>> at >>> >> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1040)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:976)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.Server.handle(Server.java:363)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:483)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:920)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:982)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)[69:org.eclipse.jetty.http:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[69:org.eclipse.jetty.http:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[73:org.eclipse.jetty.server:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)[68:org.eclipse.jetty.io:7 >> .6.8.v20121106] >>> at >>> >> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[68:org.eclipse.jetty.io:7 >> .6.8.v20121106] >>> at >>> >> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[67:org.eclipse.jetty.util:7.6.8.v20121106] >>> at >>> >> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[67:org.eclipse.jetty.util:7.6.8.v20121106] >>> at java.lang.Thread.run(Thread.java:724)[:1.7.0_25] >>> Caused by: java.io.EOFException >>> at >>> >> java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:264)[:1.7.0_25] >>> at >>> >> java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:254)[:1.7.0_25] >>> at >>> >> java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:163)[:1.7.0_25] >>> at >> java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:78)[:1.7.0_25] >>> at >> java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:90)[:1.7.0_25] >>> at >>> >> org.apache.cxf.transport.common.gzip.GZIPInInterceptor.handleMessage(GZIPInInterceptor.java:85)[151:org.apache.cxf.cxf-rt-core:2.7.3] >>> ... 22 more >>> >>> >>> Sample Request: >>> >>> >>> >>> >>> -- >>> View this message in context: >> http://cxf.547215.n5.nabble.com/GZIPInInterceptor-throws-EOFException-for-a-GET-Request-tp5743882.html >>> Sent from the cxf-user mailing list archive at Nabble.com. >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
