[PATCH] relative URIs - take 2

[Michael Becke <be...@u.washington.edu>]

Here's the patch for part 1 (the URI constructor).  Sung-Gu is correct 
about the second part.  This functionality is already covered by 
getUIReference().  If anything, I think the comments could use a little 
more work to clear up the second issue.  I'll look into that a little 
later.

Mike

Re: [PATCH] relative URIs - take 2

[Jeffrey Dever <js...@sympatico.ca>]

Committed.  Thanks!

Jandalf


Michael Becke wrote:

> Here's the patch for part 1 (the URI constructor).  Sung-Gu is correct 
> about the second part.  This functionality is already covered by 
> getUIReference().  If anything, I think the comments could use a 
> little more work to clear up the second issue.  I'll look into that a 
> little later.
>
> Mike
>
>
>
>
> On Monday, January 27, 2003, at 11:44 PM, Jeffrey Dever wrote:
>
>> (Jeff rubs his head and tries to figure out what that means)
>>
>> So you mean that this is a bug:
>>
>> - fixes the case when the second arg to URI(URI,URI) is just a fragment
>> (e.g. "#s").  According to RFC 2396 a relative reference that is just a
>> fragment should resolve to the "current document" plus the fragment.  I
>> took this to mean that URI( "http://a/b/c/d;p?q", "#s" ) should resolve
>> to "http://a/b/c/d;p?q#s".  Please let me know if this seems incorrect.
>>
>> But this is a misunderstanding:
>>
>> - changes setURI() to no longer ignores fragments, getURI() and
>> toString() now return the full URI including the fragment.
>>
>> Mike,
>> Can you seperate this into two seperate patches.  I'll commit the 
>> "first" one, but will need confirmation on the second.
>>
>>
>> Sung-Gu wrote:
>>
>>> I guess the first one may be ok.. (not second one)
>>> (Perhaps it might be compared with included test cases
>>> that it's not consistent with httpclient test cases.)
>>>
>>> Sung-Gu
>>>
>>> P.S. Someone modify them comittable to httpclient?
>>>
>>> ----- Original Message -----
>>> From: "Jeffrey Dever" <js...@sympatico.ca>
>>> To: "Commons HttpClient Project" 
>>> <co...@jakarta.apache.org>
>>> Sent: Tuesday, January 28, 2003 1:09 PM
>>> Subject: Re: [PATCH] relative URIs
>>>
>>>
>>>
>>>> Sung-Gu,
>>>>
>>>> Do you approve of this patch?
>>>>
>>>>
>>>> Sung-Gu wrote:
>>>>
>>>>
>>>>> ----- Original Message -----
>>>>> From: "Michael Becke" <be...@u.washington.edu>
>>>>> Subject: [PATCH] relative URIs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Attached is a patch and test case for a few minor bugs I 
>>>>>> discovered in
>>>>>> the URI(URI, URI) constructor.  The patch changes the following:
>>>>>>
>>>>>> - fixes the case when the second arg to URI(URI,URI) is just a 
>>>>>> fragment
>>>>>> (e.g. "#s").  According to RFC 2396 a relative reference that is 
>>>>>> just a
>>>>>> fragment should resolve to the "current document" plus the 
>>>>>> fragment.  I
>>>>>> took this to mean that URI( "http://a/b/c/d;p?q", "#s" ) should 
>>>>>> resolve
>>>>>> to "http://a/b/c/d;p?q#s".  Please let me know if this seems 
>>>>>> incorrect.
>>>>>>
>>>>>>
>>>>>>
>>>>> Isn't it?  then a bug... :(
>>>>> It seems like query not to be resolved ...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - changes setURI() to no longer ignores fragments, getURI() and
>>>>>> toString() now return the full URI including the fragment.
>>>>>>
>>>>>>
>>>>>>
>>>>> There is getURIReference().   That's not like getURI().
>>>>> Actually, URI and URI-reference is different...
>>>>>
>>>>> In common, on both protocol and document uses,
>>>>> an URI is effective...  not URI-reference.  That's why...
>>>>>
>>>>> Sung-Gu
>>>>>
>>>>> --
>>>>> To unsubscribe, e-mail:
>>>>>
>>> <ma...@jakarta.apache.org>
>>>
>>>>> For additional commands, e-mail:
>>>>>
>>> <ma...@jakarta.apache.org>
>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>> --
>> To unsubscribe, e-mail:   
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail: 
>> <ma...@jakarta.apache.org>
>>
>
>------------------------------------------------------------------------
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>