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 > > >
