On 21 April 2011 01:57, sebb <[email protected]> wrote: > On 20 April 2011 22:30, Milamber <[email protected]> wrote: >> Hello, >> >> HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut >> policy: ignore cookie seems don't works) > > Looks like this is a new bug - the example works correctly in JMeter 2.4. > > I must have messed something up when converting the HC3.1 sampler to > the new class layout. > > I'll take a look shortly.
Fixed. > >> With JMeter trunk and HC3.1 sampler, if you test a website with a login page >> which used a auth session ID cookie to keep track user session and *without* >> a JMeter cookie manager, the connection works and we can accessed on >> protected resources. >> The normal case is: if no cookie manager, we don't have a access on >> protected resources (we have a error 408 with tomcat examples) >> >> >> (an example Webapp is provided with tomcat archive : >> http://localhost:8080/examples/jsp/security/protected/ >> don't forget to uncommented users/roles in tomcat_home/conf/tomcat-users.xml >> before running tomcat) >> >> Simple test case. > > Thanks - well spotted! > >> Milamber >> >> Le 25/11/2010 16: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: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
