For folks who use JMeter to load test wicket apps and are having problems with 404s on redirect URLs containing '/..': I posted a patch to JMeter trunk that fixes the problem by simulating behavior of major browsers - collapsing the URL before issuing the successive GET:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49083 apply to JMeter trunk On Thu, Apr 8, 2010 at 12:06 PM, Nikita Tovstoles < [email protected]> wrote: > ahh, good point. I was looking at this: > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 > > <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30>Are you > suggesting it's Tomcat's responsibility to either: > > - collapse the '/../' when generating the absolute URL for the Location > response header OR > - deal with those URLs when parsing a request? > > > -nikita > > On Thu, Apr 8, 2010 at 8:35 AM, Nikita Tovstoles < > [email protected]> wrote: > >> I am working on a patch to JMeter to rewrite absolute URLs containing >> '/../' before issuing GETs and have an observation and a question. The >> problem is described here: >> http://markmail.org/thread/3ci5hayvqyjhi2ud >> >> FWIW this was discussed before and there's WICKET-2728 and related JIRAs. >> My understanding is that the reason wicket chose to break the RFC and issue >> relative URL redirects is to accommodate a 'real world' case. I can >> understand that. >> >> Unfortunately, Response.encodeRedirectURL in Tomcat will rewrite >> redirectURL to absolute anyway, thus returning Location as absolute yet >> containing '/../' that - if replayed as is - will result in a 404. (see >> toAbsolute() in >> http://kickjava.com/src/org/apache/catalina/connector/Response.java.htm). >> So the benefit derived from breaking RFC seems to be obviated, no? >> >> So, given that Tomcat is widely used container, what was the logic in >> trading off RFC compliance? Just trying to understand the philosophy. >> >> thanks >> >> -nikita >> >> >> > >
