jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Redirect encoding issues - new apporach
Date Sun, 16 Mar 2014 22:18:22 GMT
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 <philippe.mouawad@gmail.com> wrote:
> Agree, thanks for analysis
>
>
> On Fri, Mar 7, 2014 at 12:31 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 6 March 2014 17:28, Milamber <milamber@apache.org> 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.

Mime
View raw message