Agree, thanks for analysis
On Fri, Mar 7, 2014 at 12:31 PM, sebb <[email protected]> wrote: > 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. > >> > > > -- Cordialement. Philippe Mouawad.
