hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin" <sber...@gmail.com>
Subject Re: unable to encode reserved characters using java.net.URI multi-arg constructors
Date Mon, 21 Jan 2008 18:19:28 GMT
I'm also not certain why the URIs are being recreated, but it's only
done in four places in the code.  Two are within
DefaultRedirectHandler.getLocationURI, and the other two are within
DefaultClientRequestDirector.rewriteRequestURI.  One of them within
DefaultRedirectHandler seems to be harmless, since it's just for
ensuring there are no circular redirects.  The other method in
DefaultRedirectHandler already calls resolve on the newly-built URI.

To be honest I have no clue what the methods are trying to do (nor can
I understand what's going on in the resolve or relativize mehods), so
I'm not sure what'd be required to fix them.  I do think it should be
possible to basically replace whatever calls the multi-arg
constructors with a quick method toURI(multi-args) that returns a new
URI(a+b+c+d+e), essentially concatenating the non-null parts together
and returning a URI from the single-arg constructor.  Of course, that
could also fail miserably...

Tim has looked into this in much greater detail than I, so he likely
has more suggestions and/or insight than I can provide.

It should be possible to write tests that want to send a request for
something like http://localhost/file%20name?a=b&c=%26d, and see if the
server gets the correct request.  I did a quick glance through the
httpclient tests, but couldn't find a class that was testing similar
things.  Where would a test like this go? (And is there any test that
does something similar?)


On Jan 20, 2008 10:16 AM, Roland Weber <ossfwot@dubioso.net> wrote:
> Oleg Kalnichevski wrote:
> > On Sat, 2008-01-19 at 09:33 -0800, Sam Berlin wrote:
> >> It almost certainly would work, however HttpClient would then be
> >> broken (as far as URI parsing goes) for everyone else.  As others have
> >> pointed out (and as Tim explained to me in sad detail), URI is just
> >> basically broken when it comes to using it with the multi-arg
> >> constructors.  It's flat-out impossible to recreate a URI with the
> >> multi-arg constructors and have it point to the correct resource.
> >
> > What would be your suggestion on dealing with the issue? Is there anyway
> > we could avoid rewriting the whole URI class and leverage functionality
> > already available in the JRE?
> I don't know by heart where we are creating URIs. If path escaping
> is the problem, maybe we can use some workaround like:
> URI base = new URI(scheme, hostport, null);
> URI full = base.resolve(pathonly); // maps to single-arg constructor
> cheers,
>  Roland
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org

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

View raw message