Hi. I'm amazed. I've finally found time to try to isolate and reproduce, and eventually report, all the problems I mentioned in my e-mail.
To my grateful surprise, most of them (the most important, actually) are already solved in the latest release. Many many thanks to whoever has been working on these (mostly Mike, I guess). > - The HTTPSampler and the HTTP Proxy don't allow POST requests with > additional parameters in the query string (in the URI). This is solved. Thanks. > - The HTTPSampler and the HTTP Proxy fail on redirects which carry > parameters in the query string (they do the redirect but don't pass the > parameters on). This is solved. Thanks. > - The HTTPSampler generates one single Sample even if it does a > redirect. This makes debugging the scripts really difficult, because the > information on the original request is lost (you only get the page at > the end of the redirect). This is unchanged, but should be OK, since I always have the option of not following redirects (which is the default). > - It's not possible to use any unusual characters in request parameters: > the HTTPSampler will always URLEncode them -- even if they were not > encoded when the HTTP Proxy received them. This is still there and causing me trouble, but since automatic URL-encoding of parameter names and values is probably a desirable functionality, I'll probably file an enhancement request so that you can choose to URL-encode or not. > - The interface to edit the request parameters needs much improvement. I > had lots of parameter names 30 or 40 characters long which was really > hard to edit in that very small field which only accepts deleting and > writing at the end. Add a __regexp function to cope with variable form > field names and it's madness. The fields are now fully editable. Thanks. The space devoted to parameters is WAY bigger now. Thanks. > - The View Results Tree Listener is a very useful debugging tool. I was > just missing the information sent in POST requests and a "browse" > button. Would also be cool if it labelled events as per the originating > sampler, instead of the URL. A "clean" button would also be extremely > handy. The information I was missing is now there. Cool! I'll post enhancement requests for the browse button, event labelling and clean button. > - I also saw the agregate report throwing lots of > ConcurrentUpdateExceptions ... don't yet know if they are harmful. I still need to investigate this one. > - The counters in the User Parameter Modifier are not "thread safe": > each counter goes its own way. To put a simpler equivalent example: I > had registered users named "user1" to "user200" with passwords "pwd1" to > "pwd200", and I found no way to ensure each thread would properly log > in. My case was even worse because I needed to use the same number in > two consecutive pages. We need variables (not only constants) real soon > (in case they are not already there). The new __counter and __threadNum functions solve this -- at least in my case. I guess other functions can solve the issue in more general cases. Great! Salut, Jordi. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
