new URI("http://example.com/foo#bar").resolve("")

[Christopher Hegarty -Sun Microsystems Ireland]

http://bugs.sun.com/view_bug.do?bug_id=6920138

-Chris.

Jack Bates wrote:
> Thanks again Michael, is there a URL for this bug? Can I check its
> status?
> 
> On Tue, 2010-01-26 at 12:16 +0000, Michael McMahon wrote:
>> Jack,
>>
>> 6920138 is the reference for this bug.
>>
>> Thanks,
>> Michael.
>>
>> Jack Bates wrote:
>>> Hi Michael,
>>>
>>> On Mon, 2010-01-25 at 11:20 +0000, Michael McMahon wrote:
>>>   
>>>> I don't think this is a bug. Everything to the
>>>> right of the final "/" in the original URI is discarded when resolving
>>>> against any relative URI.
>>>>     
>>> I think you're referring to step 6a) in RFC2396 section 5.2,
>>>
>>>       a) All but the last segment of the base URI's path component is
>>>          copied to the buffer.  In other words, any characters after the
>>>          last (right-most) slash character, if any, are excluded.
>>>
>>> - however step 2) is,
>>>
>>>    2) If the path component is empty and the scheme, authority, and
>>>       query components are undefined, then it is a reference to the
>>>       current document and we are done.  Otherwise, the reference URI's
>>>       query and fragment components are defined as found (or not found)
>>>       within the URI reference and not inherited from the base URI.
>>>
>>> In my example the path component is empty and the scheme, authority, and
>>> query components are undefined, which is why I expect it to return,
>>> "http://example.com/foo"
>>>
>>> There's also an example in appendix C.2,
>>>
>>>    An empty reference refers to the start of the current document.
>>>
>>>       <>            =  (current document)
>>>
>>> RFC3986 section 5.4.1 gives some more examples,
>>>
>>>    Within a representation with a well defined base URI of
>>>
>>>       http://a/b/c/d;p?q
>>>
>>>    a relative reference is transformed to its target URI as follows.
>>>
>>>    [...]
>>>
>>>    ""              =  "http://a/b/c/d;p?q"
>>>
>>> - however when I run,
>>>
>>> import java.net.URI;
>>>
>>> public class Test
>>> {
>>>   public static void main(String[] args) throws Exception
>>>   {
>>>     System.out.println(new URI("http://a/b/c/d;p?q").resolve(""));
>>>   }
>>> }
>>>
>>> - instead of "http://a/b/c/d;p?q", it outputs,
>>>
>>> $ java Test
>>> http://a/b/c/
>>> $ 
>>>
>>> RFC3986 section 5.2.2 also includes,
>>>
>>>             if (R.path == "") then
>>>                T.path = Base.path;
>>>
>>>   
>>>> So, "foo#bar" is correctly discarded, leaving the new URI
>>>>
>>>> http://example.com/
>>>>
>>>> That would be my reading of RFC2396 anyway.
>>>>
>>>> - Michael.
>>>>
>>>> Jack Bates wrote:
>>>>     
>>>>> new URI("http://example.com/foo#bar").resolve("")
>>>>>
>>>>> ^ I expect this to return "http://example.com/foo", but when I run,
>>>>>
>>>>> import java.net.URI;
>>>>>
>>>>> public class Test
>>>>> {
>>>>>   public static void main(String[] args) throws Exception
>>>>>   {
>>>>>     System.out.println(new URI("http://example.com/foo#bar").resolve(""));
>>>>>   }
>>>>> }
>>>>>
>>>>> - it outputs,
>>>>>
>>>>> $ java Test
>>>>> http://example.com/
>>>>> $ 
>>>>>
>>>>> Do you think this is a bug?
>>>>>
>>>>> I'm running OpenJDK 6, but I can find only cosmetic differences between
>>>>> URI.java in the version I'm running and URI.java in,
>>>>> http://www.java.net/download/openjdk/jdk7/promoted/b80/openjdk-7-ea-src-b80-21_jan_2010.zip
>>>>>
>>>>> - so I assume the issue (if it is an issue) still exists?
>>>>>   
>>>>>       
>>>>     
>>>   
>>
> 
>