On 6 March 2014 17:28, Milamber <[email protected]> wrote: > > Le 06/03/2014 10:28, sebb a ecrit : > >> We still have not solved all the redirect encoding issues. >> This time the problem is that too many characters are being encoded. >> >> At present we massage the Location header when it is received from the >> server. >> This means that failures can potentially affect the current sample, as >> well as taking additional processing time. >> >> It occurs to me that it would be better to store the Location header >> in the response exactly as received from the server, rather than >> trying to fix it up first. >> >> The location would then need to be fixed up (if necessary) as part of >> following the redirect. >> >> This corresponds more closely with how we process the initial sample - >> in fact we may be able to use much of the same code, which presumably >> does not have the excess encoding issue, or we would be getting bug >> reports for that as well. >> >> Does that make sense? > > > Yes seems that is a better approach.
Further investigation shows that this approach is what the Java and Soap samplers have always done. The redirect location processing occurs in HTTPSamplerBase#followRedirects() So that method likely needs extending to cover the cases which are now being directly handled in the HC3 and HC4 samplers. II'll raise a bug to move the processing out of HC3/HC4 and link that to the various redirect bugs that have been fixed/are still outstanding. Hopefully that will make it easier to track progress and to document the changes for the archives. >> If so, I'll make a start on it soon. >> >
