[ http://issues.apache.org/jira/browse/HTTPCLIENT-587?page=all ]
Gordon Mohr updated HTTPCLIENT-587:
-----------------------------------
Attachment: httpclient-587.patch
Patch with unit test illustrating problem, and patch which resolves unit test
without breaking any prior unit tests.
Theory of patch is:
(1) There is a block that previously ran when relative._scheme !=null -- it
assumed this meant 'relative' was an absolute URI and copied all its state into
the new URI instance. Now, this block only runs if scheme !=null AND either the
relative._scheme is different than the 'base' scheme (meaning no
derelativization would be appropriate) or relative._authority is non-null
(implying it truly is an absolute URI)
(2) There is a block for derelativizing the path that previously ran only when
relative._scheme and relative._authority were both null -- assuming that this
was the only case where combining the paths was necessary. Now, this block also
runs when relative._authority is null and the relative._scheme is identical to
the base_scheme.
(3) The early setting of this._authority to base._authority (~line 6 of method)
counts on authority being reset later if necessary. It appears the same tack
should be taken with _is_net_path; otherwise the later setURI() will not retain
the set-up _authority.
> derelativizing of relative URIs with a scheme is incorrect
> ----------------------------------------------------------
>
> Key: HTTPCLIENT-587
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-587
> Project: Jakarta HttpClient
> Type: Bug
> Versions: 3.0.1
> Reporter: Gordon Mohr
> Attachments: httpclient-587.patch
>
> URI constructor "public URI(URI base, URI relative) throws URIException"
> assumes that if given 'relative' URI has a scheme, it should provide an
> authority and complete path to the constructed URI. However, a URI can have a
> scheme but still be relative, requiring the authority and base path of the
> 'base' URI.
> Demonstration code:
> URI base = new URI("http://www.example.com/some/page";);
> URI rel = new URI("http:boo");
> URI derel = new URI(base,rel);
> derel.toString();
> (java.lang.String) http:boo
> In fact, derel should be "http://www.example.com/some/boo";.
> RFC2396 is a little confused about this; section 3.1 states ""Relative URI
> references are distinguished from absolute URI in that they do not begin with
> a scheme name." But, in section 5, there are several sentences talking about
> relative URIs that begin with schemes (and how this prevents using relative
> URIs that have leading path segments that look like scheme identifiers).
> RFC3896, which supercedes RFC2396, removes the implication a relative URI
> cannot begin with a scheme, leaving the other text explcitly discussing
> relative URIs with schemes.
> Both Firefox (1.5) and IE (6.0) treat "http:boo" the same as "boo" for
> purposes of derelativization against an HTTP base URI, which would give the
> final URI "http://www.example.com/some/boo"; in the example above.
> Even relative URIs like "http:../../boo" are explicitly legal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
