>> When Web server (Apache 2.2) uses mod_deflate to compress response data, >> the data remains compress data (in view results tree, we have the >> compress characters and getBytes() is the compressed length) >> >> I thinks that must add a code section in sample() method when JMeter >> reads response data, to decode GZip response if needs, like HC3Impl? >> (perhaps HC4 has a specific method to do this?) >> > HC4 should do this automatically, I think, but there was a bug whereby > it did not recognise some encoding methods: > > https://issues.apache.org/jira/browse/HTTPCLIENT-1063 > > As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which > JMeter trunk was recently updated to use). > > Can you check which version of HC4 you were using, and the > Content-type used by Apache 2.2? >
I uses last JMeter with HC v4.1.1 httpclient-4.1.1.jar httpmime-4.1.1.jar and httpcore-4.1.jar Response headers (extract) : Server: Apache/2.2.16 (Unix) DAV/2 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 70 Request Headers: Connection: keep-alive Accept-Encoding: gzip,deflate (I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue) Issue too with www.google.com Milamber > >> Milamber >> >> >> Le 25/11/2010 15:45, sebb a ecrit : >> >>> Just a heads up that I'm currently working on trying to combine the >>> HTTP implementations (Java, HttpClient3) into a single GUI, with >>> run-time choice of implementation. >>> >>> The rationale for this is that HttpClient 4 is now available, and it >>> would be good to add that, but I think we should keep HttpClient for >>> backwards compatibility and comparison. >>> >>> Creating another GUI/Sampler set is easy enough, but it would be >>> useful to be able to switch implementations easily - currently that >>> requires switching samplers (e.g. by editting the JMX file). >>> >>> The current plan is to allow the implementation to be specified on the >>> HTTP Request Defaults config screen as well as on the HTTP Request >>> screen. >>> >>> The code is a bit involved, because the Config settings are processed >>> at run-time after the test plan has been built. >>> [But even the Sampler GUI needs to create the sampler before it can >>> store the sampler settings - and the implementation can then be >>> changed.] >>> Currently I use a Sampler Proxy that dispatches to the appropriate >>> implementation class. >>> These classes have to extend an abstract class that provides the >>> necessary methods to interface with the Proxy test element and thus >>> provide access to the test element properties. >>> That part seems to be working OK. >>> >>> The next phase is to ensure that existing JMX files can be converted >>> (during load) to use the new sampler. >>> >>> The intention is to keep the existing Java and HttpClient samplers, so >>> that subclasses will continue to work, but not expose them in the GUI. >>> >>> I've not finally decided about the AJP sampler - it can be easily >>> converted, but I don't think there's much of a use case for switching >>> between AJP and another implementation. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
