hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Armando Anton" <armando.an...@newknow.com>
Subject RE: [PATCH] relative URIs - take 2
Date Tue, 28 Jan 2003 14:18:46 GMT
i think that the problem #2 tipically exists when someone writes too many ".." expressions
without safety and then the idea of compensating author errors sounds fine for me (but it
is just an idea)

in the current code if the base uri is http://a/b/c/d;p?q and the relative uri is ../../../g
then the new uri is http://a
and this is an error (perhaps the lowest problem in httpclient :) )


-----Original Message-----
From: Eric Johnson [mailto:eric@tibco.com]
Sent: martes, 28 de enero de 2003 15:01
To: Commons HttpClient Project
Subject: Re: [PATCH] relative URIs - take 2

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>

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