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

[Jack Bates]

Thanks Chris

On Tue, 2010-03-09 at 17:41 +0000, Christopher Hegarty -Sun Microsystems
Ireland wrote:
> 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?
> >>>>>   
> >>>>>       
> >>>>     
> >>>   
> >>
> > 
> > 
> 
>