On 09/02/2010, Alexander Fisher <[email protected]> wrote: > On 8 February 2010 15:01, sebb <[email protected]> wrote: > > On 04/02/2010, Alexander Fisher <[email protected]> wrote: > >> On 4 February 2010 22:07, sebb <[email protected]> wrote: > >> > On 04/02/2010, Alexander Fisher <[email protected]> wrote: > >> >> On 4 February 2010 16:29, sebb <[email protected]> wrote: > >> >> > On 04/02/2010, Alexander Fisher <[email protected]> wrote: > >> >> >> Hi > >> >> >> > >> >> >> I'm trying to test a wicket application using JMeter. > >> >> >> > >> >> >> JMeter doesn't seem to be following certain redirects in the > same way > >> >> >> browsers do. Specifically, I was testing logging out of the > >> >> >> application. > >> >> >> > >> >> >> The wicket code for this looks a bit like. > >> >> >> > >> >> >> public class SignOutLink extends Link { > >> >> >> -SNIP- > >> >> >> @Override > >> >> >> public final void onClick() { > >> >> >> WicketAppSession.get().invalidate(); > >> >> >> getRequestCycle().setRedirect(true); > >> >> >> setResponsePage(SignInPage.class); > >> >> >> } > >> >> >> } > >> >> >> > >> >> >> The logout link is to a wicket encrypted URL which then > redirects to ./ > >> >> >> > >> >> >> If I get a redirect to http://host/wicket-app/./ I get either a > 404 or > >> >> >> a web server directory listing (if listings are enabled). > >> >> >> Entering the same URL into firefox I get the application's sign > in > >> >> >> page (http://host/wicket-app/) as expected. > >> >> >> > >> >> >> Is this a known issue, or something I can work around? > >> >> > > >> >> > What redirect options are you using? > >> >> > > >> >> > If you are using redirect automatically, then JMeter does not see > any > >> >> > redirects, and thus won't be able to process any cookies that > might be > >> >> > set during the process. > >> >> > This is documented here: > >> >> > > >> >> > > http://jakarta.apache.org/jmeter/usermanual/component_reference.html#HTTP_Request > >> >> > > >> >> > Try "Follow redirects"; if that fails, you will have to add the > URLs manually. > >> >> > >> >> > >> >> I've tried both 'follow redirects' and 'redirect automatically'. > >> >> I think it's just that the url returned in the 302 returns a > different > >> >> result when fetched using firefox, compared to JMeter. > >> >> > >> >> Could it be that firefox automatically removes all dot-slashes > >> >> ('./''s) from URLs before forming the request? > >> >> Should JMeter mimic this behaviour? > >> > > >> > No idea. > >> > > >> > Please provide more details of what you expected to happen and what > >> > actually happened. > >> > >> > >> Firstly, thank you for taking the time to help me. > >> Whilst writing this rather long winded post (concise emails not a > >> forte!), I think I've found the answer. > >> Somebody searching the archives might benefit, so I'll continue :) > >> > >> I was trying to login to a wicket based webapp and then signout again. > >> It's my first use of JMeter, so I thought I'd start with this really > >> simple testcase. > >> The webapp uses wicket, so things are made a bit more complicated by > >> the dynamically generated urls, > >> but I think I've got that figured out using the regex extractor feature. > >> > >> These are the rough steps. > >> > >> 1. Navigate to website. Assert that I'm actually there. Use the regex > >> extractor to find the URL for the sign in form. > >> 2. Sign in, run another assertion then perform another regex extract > >> to get the sign out link url. > >> 3. 'Click' signout link with url extracted from previous step and > >> assert that I'm back on the sign in page. > >> > >> Everything works as expected when using a browser, but when using > >> jmeter the sign out 'click' lands on a 404 page. > >> > >> The sign out link is to a URL such as > >> > "?x=YwbAGQPpvT9MHF2-6S6FwvocqYPuA0B8WNUAt2TlZ9pH*NSINgi53u5hmLOyTe6xOBKzTV*kN0M", > >> wicket invalidates the session then returns a 302 with the new url set > >> to "./" > >> > >> JMeter doesn't handle the "./" in the same way firefox does. > >> However, it turns out that it's not just JMeter. > >> > >> http://issues.apache.org/jira/browse/WICKET-2600 > >> > > > > The Wicket fix is wrong - Location URLs are supposed to be absolute: > > > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 > > > > I've raised WICKET-2728. > > > > However many sites incorrectly return relative URLs for redirections > > within the site, so many browsers allow for this broken behaviour. > > > > JMeter also assumes that Location: references can be relative, and > > uses java.net.URL(URL urlBase, String spec) to convert them, so I > > don't know why you are seeing a difference from the browser. > > > > Note that you can specify URLs ending in "." or "./" in the HTTP > > samplers in which case the URL is not converted - only redirects are > > converted. > > > I don't think the location is being converted, hence the 404. > The Location in the 302 is of the form ... > > Location: http://host/wicket-app/. (this is with the WICKET-2600 > 'fix' which doesn't fix the issue for me)
Yuk! > and my apache, (apache is being used as a loadbalancer for glassfish), > access logs show the URL having not been converted. > > 192.168.24.2 - - [09/Feb/2010:10:06:39 +0000] "GET > /wicket-app/?x=ALxUK81PW-4dxeAVOUmqAxDJ2H8DvDqhJxpmT1dW0*7TF1ApuMic6w > HTTP/1.1" 302 - "-" "Jakarta Commons-HttpClient/3.1" > 192.168.24.2 - - [09/Feb/2010:10:06:39 +0000] "GET /wicket-app/. > HTTP/1.1" 404 1022 "-" "Jakarta Commons-HttpClient/3.1" > > My guess is that the problem is that wicket isn't returning a relative > URL, but an absolute URL with relative bits in (if that makes any > sense). Yes, that now makes sense - unlike the Wicket fix! JMeter will only convert relative URLs if they really are relative. It doesn't fix up absolute URLs, unlike some browsers (and some servers). I suggest you re-open the Wicket bug (or open a new one) and quote the broken Location: response to them. > Kind Regards, > Alex > > --------------------------------------------------------------------- > 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]
