On 6 April 2011 23:11, Milamber <milam...@apache.org> wrote: > >>> 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
Thanks, that was useful, though strangely google would not gzip until I added a User-Agent of Firefox. Accepting gzip was not enough. Code now fixed - HC4 does support gzip decoding, but not by default. > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org