Bug 46690 - handling of 302 redirects with invalid relative paths
Summary: handling of 302 redirects with invalid relative paths
Status: RESOLVED FIXED
Alias: None
Product: JMeter - Now in Github
Classification: Unclassified
Component: HTTP (show other bugs)
Version: 2.3.2
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-10 14:56 UTC by John Hare
Modified: 2009-04-03 04:36 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Hare 2009-02-10 14:56:11 UTC
When JMeter submits the following request:
http://www.website.edu/MasterIncludes/toaspnet.asp?dest=c_tmodule/tm_step1.aspx

And receives a response as follows (note the double "../../"):
HTTP/1.x 302 Object moved
Location: ../../wiscareers_net/tonet.axd?dest=c_tmodule/tm_step1.aspx&id=bbuI5wrZ12Y=&

And it's set to follow redirects, JMeter will follow up with a request
to the URL:
http://www.website.edu/../wiscareers_net/tonet.axd?dest=c_tmodule/tm_step1.aspx&id=bbuI5wrZ12Y=&

Which is an invalid URL.

Real browsers (Firefox, IE, Safari) will redirect to:
http://www.website.edu/wiscareers_net/tonet.axd?dest=c_tmodule/tm_step1.aspx&id=bbuI5wrZ12Y=&

This is an enhancement request such that JMeter will handle these relative URLs in the same manner as the primary browsers handle them.
Comment 1 Jason Barnabe 2009-03-06 12:38:20 UTC
This is not limited to redirects. It also happens with URLs entered directly and those loaded via "Retrieve All Embedded Resources from HTML files".

When loading relative URLs, Firefox, IE, and others will resolve to an absolute URL before making the request, so if you enter "http://example.com/a/..", they will attempt to load "http://example.com/". JMeter, on the other hand, will attempt to load "http://example.com/a/..". In this case, both URLs work, so there's no issue. But in the case of "http://example.com/../", the browsers will notice the error and correct it to "http://example.com/" before sending, while JMeter won't and will receive a 400 from the server.

RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt) section 5.2 provided an example algorithm for resolving relative references.
Comment 2 Sebb 2009-04-03 03:45:21 UTC
JMeter currently uses  new URL(baseURL, location)  to handle the references.

This behaves correctly according to RFC2396, which states:

5.2.
<snip/>
 g) If the resulting buffer string still begins with one or more
         complete path segments of "..", then the reference is
         considered to be in error.  Implementations may handle this
         error by retaining these components in the resolved path (i.e.,
         treating them as part of the final URI), by removing them from
         the resolved path (i.e., discarding relative levels above the
         root), or by avoiding traversal of the reference.

Java takes the first option, i.e. it leaves the component in the resolved path.

It seems that browsers take the second option, i.e. discarding extra levels.

JMeter will need to perform further processing to remove any additional relative levels.
Comment 3 Sebb 2009-04-03 04:36:01 UTC
URL: http://svn.apache.org/viewvc?rev=761626&view=rev
Log:
Bug 46690 - handling of 302 redirects with invalid relative paths.
JMeter now removes extraneous leading "../" segments (as do many browsers)

It will be in nightlies after r761626
Comment 4 The ASF infrastructure team 2022-09-24 20:37:43 UTC
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2200