Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Message-ID: <3F1ECB99.4050002@mac.com>
Date: Wed, 23 Jul 2003 18:53:29 +0100
From: Mike Moran <mike_moran@mac.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3b) Gecko/20030210
MIME-Version: 1.0
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
Subject: Re: normalizing a URI with ..'s in it ?
References: <20030723151940.GB21113@managesoft.com>
 <3F1EC47C.8080608@u.washington.edu>
In-Reply-To: <3F1EC47C.8080608@u.washington.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Michael Becke wrote:
> Though I agree this seems a little strange I am not sure it's a bug. 
> URI.normalize() is using the algorithm defined at 
> <http://www.apache.org/~fielding/uri/rev-2002/issues.html> which 
> corresponds to the latest update(I believe) to rfc2396.  

[ removed algorithm ]

Btw, I presume this is the algorithm given in section 5.2 of 
http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html#absolutize? 
  If so, this is just a draft (draft-fielding-uri-rfc2396bis-03.txt). It 
does actually differ from rfc2396 in how it handles abnormal URLs 
(though I think that's irrelevant here).

> And we're done.  Perhaps we should send and email to URI@w3.org and see 
> if they have any input.  Does anyone else have an opinion about this?

The string "my/relative/../../another/relative" would never be output 
from merge() or given to remove_dot_segments() in the section 5.2 
algorithm. If you are just applying remove_dot_segments() to this string 
then it will get confused and output a wierd answer because it's not 
expecting that input (ie a path that doesn't have a "/" at the start).

I may be wrong, but I didn't think normalization could be applied to 
anything but absolute URLs.

-- 
Mike