hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gordon Mohr (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HTTPCLIENT-587) derelativizing of relative URIs with a scheme is incorrect
Date Fri, 16 Jun 2006 23:43:30 GMT
     [ 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:
For more information on JIRA, see:

To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message