#20 WinstoneResponse.sendRedirect and relative path

[Kohsuke Kawaguchi]

When I pass in relative paths in the sendRedirect() method, such as "." or "../foobar", Winstone doesn't resolve them and instead simply appends it. The resulting Location header gets weird because of this, such as:

Location http://foobar/abc/../def/ghi
Location http://foobar/abc/def/.

Browsers seem to be able to handle some of them (both IE and FireFox resolves ".." by themselves before sending the next request), but IE cannot handle "abc/def/." format and thus the redirect fails.

The spec of the sendRedirect method says:

/**
* Sends a temporary redirect response to the client using the
* specified redirect location URL. This method can accept relative URLs;
* the servlet container must convert the relative URL to an absolute URL
* before sending the response to the client. If the location is relative
* without a leading '/' the container interprets it as relative to
* the current request URI. If the location is relative with a leading
* '/' the container interprets it as relative to the servlet container root.

And the normal interpretation of "resolving relative URL" includes handling of "." and "..", so I consider this a Winstone bug.

Other containers such as Jetty and Tomcat does this correctly.

[Rick Knowles]

Logged In: YES
user_id=716353
Originator: NO

Strictly speaking this isn't a spec bug, since the form you mention is the canonical URL form, and there's nothing in the spec about a requirement for resolution to canonical form. Java's java.io.File class actually has the same behaviour as winstone does when you call getAbsolutePath() instead of getCanonicalPath(). The point I guess is that the word "resolve" is very vague without some reference regarding "resolve to XXX form".

I do however agree with you that it's not pretty, and that the above not handling of "." is a bug. The amount of code required to fix something as trivial as this is unfortunately large, hence my reticence, but I'll see if I can come up with a way of stopping the browser incompatibility without requiring a full canonical form resolution.

Thanks for pointing out a case where it doesn't work.

[Kohsuke Kawaguchi]

Logged In: YES
user_id=179238
Originator: YES

If you can just fix sendRedirect("."), that would be very helpful.

Beyond that, I still think you can relatively easily get it right by first tokenizing by "/" and then manipulating the resulting list.

[Rick Knowles]

Logged In: YES
user_id=716353
Originator: NO

Just committed a check for the "." case.

I thought the same thing about it being easy before the last time I did it, and given that it's only a cosmetic thing for a URL that no-one will ever see, I wouldn't be willing to add it unless it was done in less than a two or three hundred bytes of bytecode (size is part of winstone's value proposition). My last experience tells me that isn't possible.

Anyway, hope this solves your problem, even if it isn't pretty.