Hi, On 09/02/12 17:54, jmoore wrote:
Dear All, I am having a problem where when I enable GZIP compression in CXF (via GZIPOutInterceptor or GZIPFeature) the Content-Length header is set to the pre-compressed length of the message body. This results in the client (in most cases a browser) waiting for the remaining bytes that never come and the request eventually times out.I did some debugging and it seems that value for the Content-Length header is retrieved from the BianryDataProvider (MessageBodyWriter) well before the content of the message body is compressed. Is there anything I can do to ensure that the correct Content-Length header value is set? Am I better off compressing at the Tomcat/JBOSS level as opposed to the CXF level? Any help would be very much appreciated. Thanks a bunch!
As far as I recall BinaryDataProvider will only attempt to offer a valid getSize() value if byte[] array is returned from a resource method. Can you return InputStream or File (if suitable) ? Another option is to either extend the default BinaryDataProvider or simply create a custom MessageBodyWriter which will handle byte[] & return -1 in getSize().
I'll check what can be done when byte[] is returned and GZIP is used, Perhaps BinaryDataProvider should simply return -1 in getSize() because attempting to optimize for byte[] may be a bit futile...
Thanks, Sergey
-Jennifer -- View this message in context: http://cxf.547215.n5.nabble.com/Incorrect-Content-Length-header-value-set-when-GZIP-compression-enabled-tp5470230p5470230.html Sent from the cxf-user mailing list archive at Nabble.com.
-- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
