I'm willing to improve handling of HTTP redirects in Sampler and Proxy.

[Jordi Salvat i Alabart <js...@atg.com>]

Hi.

This is my first message to this list, so please bear with me if I'm 
breaking any rules/customs.

I'm re-reading this message before sending it and noticed its much too 
long, so here's a summary:

- I'm working towards adding a "follow redirects" configuration flag to 
the HTTP Samplers, so as to allow correcting the way the HTTP Proxy 
Server handles redirects. I will also make an effort to correct related 
comments.

- I'd like to confirm noone else is working in the same direction(s).

- I would appreciate someone who knows the code better than I to have a 
look at my description of the issue (below) and warn me if I've 
seriouldy misunderstood the code and any traps for the unwary she's 
aware of.

End of summary. Here's the full story:

I've been having trouble with the handling of HTTP redirects (302 return 
codes with a Location: header) by the HTTP Proxy Server. You can 
reproduce my problem simply by using the proxy and pointing at any page 
which redirects to a page in a different directory (for example, try 
http://bugs.debian.org/).

The problem occurs because the proxy is following these client-side 
redirects by itself, and so the client never learns the redirect has 
happened and the base URL has changed (much as in "server-side" 
redirects). As a consequence, all relative URLs in the resulting page 
will be wrong.

To solve this, I would need the Proxy Server to handle redirects back to 
the client as any other HTTP proxy (or at least as any other I've seen 
so far).

But then the proxy server would add both URLs (the original and the 
redirected one) to the test case, which then, when run, would cause the 
page to be requested twice. One quick solution to this would be not to 
record the first URL, but this would change the nature of the test. The 
right(TM) solution is to be able to record URLs in such a way that 
redirects won't be followed.

I've been reviewing the HTTPSampler code and I've found the comments and 
code related to the handling of redirects quite strange. It seems to 
have gone through some changes over time which have made it pretty 
confusing. To start with, comments describe the "redirected" parameter 
as "whether redirection is turned on", but it rather seems to mean 
"whether we're processing a redirect", and seems to be used used to 
avoid following more than one level of redirection.

I've tested a two-level redirect (page1->page2->page3) and the proxy 
does the redirect from page1 to page2, but then handles the second 302 
response  to the client, which does the redirect to page3. The URLs of 
page1 and page3 get recorded, but not that for page2. I consider this a bug.

Is there a reason I can't think of to avoid multi-level redirects?

Is there a reason I can't think of to have the proxy do the redirections 
instead of the client?

To solve all of this, I'm adding a "follow redirects" boolean property 
to the HTTP Sampler(s) (of course the default will be "true" so as to 
stay compatible with the old behaviour). Do you think this is a sensible 
working direction? Is anyone already working in this direction?

In the process, I'm doing my best to correct the comments, and I will 
also remove that multi-level redirect limitation (unless someone tells 
me I shouldn't).

Next step will be to have the HTTP Proxy use HTTP Samplers with 
followRedirects turned off. I think this will solve the problems I'm 
having while recording. Again: Is this sensible? Is anyone working in 
this same direction?

I'll submit my changes once I've tested them. This should hopefully be 
sometime next week.

Of couse, being novice to this code, I will appreciate any 
hints/directions/suggestions you may have.

Salut,

Jordi.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>