hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: [PATCH] relative URIs - take 2
Date Tue, 28 Jan 2003 14:01:09 GMT
I'll go with whatever others suggest with problem #1.

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.


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:commons-httpclient-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-httpclient-dev-help@jakarta.apache.org>

View raw message