On 7 April 2011 00:07, sebb <seb...@gmail.com> wrote: > On 6 April 2011 23:36, Milamber <milam...@apache.org> wrote: >> >>> HC4 should do this automatically, I think, but there was a bug whereby >>> >> >> I have found this problem too: >> Unlike HC3, HC4 sampler works with a HTTPS website with a trusted >> certificate (verisign, thawte, etc.) but doesn't works with self-signed >> ssl certificate. >> I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal? > > No, I forgot. > That needs to be fixed so that all certificates are accepted, same as for HC3. > I'll fix that shortly.
Fixed. >> Milamber >> >> >>> 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? >>> >>> >>>> 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
