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 Tue, 22 Jan 2008 02:58:12 GMT
So... I got bored and had a little time.  Here's a testcase which
highlights the URI-rewrite changing the URI for requests.  It only
tests one example of the URI failures right now:
DefaultClientRequestDirector.rewriteRequestURI's else branch.  I'm not
positive how to setup the environment to test the if branch.  The
other tests can be added to TestRedirects.

Only two testcases fail: testEscapedAmpersandInQueryAbsolute, and
testEscapedAmpersandInPathAbsolute.  The relative requests pass,
because no URI-rewriting is done there.

There's probably many more (and other) ways to test it, but assuming
no special-casing is done in the core to look for ampersands and do
things specially, whatever fixes this should fix other problems.


On Jan 21, 2008 1:19 PM, Sam Berlin <sberlin@gmail.com> wrote:
> 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?)
> Sam
> 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
> >
> >

View raw message