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" <[EMAIL PROTECTED]> To: "Commons HttpClient Project" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > >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: <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >
uri.jar
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
