It's trivial to delegate the Location handling code to the shared code. However, the problem is knowing exactly what encoding of special characters (if any) should be done.
According to the RFC2616, the Location header is supposed to be an absolute URI. However most browsers accept relative URIs, and there is a proposal [1] to relax the rules. Converting to an absolute URI is quite easy - both URL and URI classes have relocation ctors or methods. In any case, the location string needs to be a URI which means it must be properly encoded. It seems that servers (at least Apache http and Tomcat) pass the redirect location without encoding, i.e. they require valid (encoded) URIs. However, they don't warn if the location is not correctly encoded, and it seems some servers have been set up with unencoded locations. Unfortunately, in general it is not possible to tell if a given string has been encoded or not. So I think the best might be to see if the location can be converted to an URI, and if not, encode it. Otherwise there is a danger that a properly encoded URI will be corrupted by being double-encoded. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-7.1.2 On 7 March 2014 14:42, Philippe Mouawad <[email protected]> wrote: > 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.
