[ https://issues.apache.org/jira/browse/HTTPCLIENT-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168153#comment-14168153 ]
Oleg Kalnichevski edited comment on HTTPCLIENT-1564 at 10/11/14 1:43 PM: ------------------------------------------------------------------------- Gary, The test is using a very outdated ContentEncodingHttpClient which was deprecated in 4.2. This class does not remove 'Content-Length', 'Content-Encoding' and 'Content-MD5' response headers if response content gets automatically decompressed. Newer versions of HttpClient do. The problem with leaving those headers in the response object is that they no longer correspond to content stream properties. You can even see it with your own test. The actual content length is 149011, whereas the value of 'Content-Length' is 696. This is obviously wrong. You should adjust your test a little and instead of testing for presence of 'Content-Encoding' response header test the content stream type {code:java} final DefaultHttpClient client = new ContentEncodingHttpClient(); HttpConnectionParams.setConnectionTimeout(client.getParams(), 5000); final HttpGet request = new HttpGet(getServerUrlStringForFiles() + "/BigHelloWorld.txt"); final HttpResponse response = client.execute(request); // check that response is compressed final HttpEntity entity = response.getEntity(); InputStream contentStream = entity.getContent(); Assert.assertTrue(contentStream instanceof GZIPInputStream); // decompress final byte[] content = EntityUtils.toByteArray(entity); Assert.assertEquals(149011, content.length); // check that contents is OK ImageIO.read(new ByteArrayInputStream(content)); {code} was (Author: olegk): Gary, The test is using a very outdated ContentEncodingHttpClient which was deprecated in 4.2. This class does not remove 'Content-Length', 'Content-Encoding' and 'Content-MD5' response headers if response content gets automatically decompressed. Newer versions of HttpClient do. The problem with leaving those headers in the response object is that they no longer correspond to content stream properties. You can even see it with your own test. The actual content length is 149011, whereas the value of 'Content-Length' is 696. This is obviously wrong. You should adjust your test a little and instead of testing for presence of 'Content-Encoding' response header test the content stream type {code:java} final DefaultHttpClient client = new ContentEncodingHttpClient(); HttpConnectionParams.setConnectionTimeout(client.getParams(), 5000); final HttpGet request = new HttpGet(getServerUrlStringForFiles() + "/BigHelloWorld.txt"); final HttpResponse response = client.execute(request); // check that response is compressed final HttpEntity entity = response.getEntity(); InputStream contentStream = entity.getContent(); Assert.assertTrue(contentStream instanceof GZIPInputStream); final DefaultHttpClient client = new ContentEncodingHttpClient(); HttpConnectionParams.setConnectionTimeout(client.getParams(), 5000); final HttpGet request = new HttpGet(getServerUrlStringForFiles() + "/BigHelloWorld.txt"); final HttpResponse response = client.execute(request); // check that response is compressed final HttpEntity entity = response.getEntity(); InputStream contentStream = entity.getContent(); Assert.assertTrue(contentStream instanceof GZIPInputStream); // decompress final byte[] content = EntityUtils.toByteArray(entity); Assert.assertEquals(149011, content.length); // check that contents is OK ImageIO.read(new ByteArrayInputStream(content)); // decompress final byte[] content = EntityUtils.toByteArray(entity); Assert.assertEquals(149011, content.length); // check that contents is OK ImageIO.read(new ByteArrayInputStream(content)); {code} > ContentEncodingHttpClient 4.3.5 breaks compat with 4.2.5 > --------------------------------------------------------- > > Key: HTTPCLIENT-1564 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1564 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient > Affects Versions: 4.3.5 > Environment: Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_67\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > Reporter: Gary Gregory > > I have a test that fails after updating from 4.2.5 to 4.3.5. > The test looks like this: > {code:java} > public void testCompressionSanityCheck() throws IOException { > final DefaultHttpClient client = new ContentEncodingHttpClient(); > HttpConnectionParams.setConnectionTimeout(client.getParams(), 5000); > final HttpGet request = new HttpGet(getServerUrlStringForFiles() + > "/BigHelloWorld.txt"); > final HttpResponse response = client.execute(request); > // check that response is compressed > final Header h = > response.getFirstHeader(HttpHeaders.CONTENT_ENCODING); > if (h != null) { > LOG.info("Response is " + h.getValue() + " encoded"); > } else { > Assert.fail("Response is not encoded"); > } > final HttpEntity entity = response.getEntity(); > // decompress > final byte[] content = EntityUtils.toByteArray(entity); > Assert.assertEquals(149011, content.length); > // check that contents is OK > ImageIO.read(new ByteArrayInputStream(content)); > } > {code} > The server side is a custom servlet running in Jetty 8.1.15. > The failure: > {noformat} > java.lang.AssertionError: Response is not encoded > at org.junit.Assert.fail(Assert.java:88) > at > com.seagullsw.appinterface.server.comm.jetty.JettyHttpCompressedContentTestCase.testCompressionSanityCheck(JettyHttpCompressedContentTestCase.java:179) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org