On 20 April 2011 22:30, Milamber <milam...@apache.org> 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. > 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: 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
