Problem #2, I think, deserves an exception, rather than a silent adjustment. If you sent "http://a/../g"; to either Tomcat or Apache, I believe both will actually ignore the request and log it as an attempted hack, so we definitely shouldn't take that option. The result of "http://a/g"; is misleading, and will lead to unintended consequences that are harder to identify and figure out than if you threw an exception in the first place. Imagine, for example, that your client application follows a link in an HTML that generated this URL, and the file "g" actually exists on the server. Everything will appear to be operating correctly, but it is not.
-Eric.
Michael Becke wrote:
1. when the relative uri is empty > an exception is thrown (i think it is a good idea to avoid empty uris)
We should probably handle this one. Looks like parseUriReference() will need to be changed to handle an empty URI.
2. when there are more relative path ".." segments than hierarchical levels in the base uri's path (the ".." expression must not change the authority component of a uri). There are two options here:
base: http://a/b/c/d;p?q
relative: ../../../g
option1: http://a/../g
option2: http://a/g (compensating author errors)
Option 2 sounds good here.
Mike
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
