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 03:24:31 GMT
FWIW, replacing the else branch in
DefaultClientRequestDirector.rewriteRequestURI with
-- 
                String path = uri.getRawPath();
                String query = uri.getRawQuery();
                String fragment = uri.getRawFragment();
                String newUri =
                (path == null ? "" : path)
                 + (query == null ? "" : ("?" + query))
                     + (fragment == null ? "" : ("#" + fragment));
                request.setURI(new URI(newUri));
-- 

fixes the test.  I don't know how stable that is, though, and it
certainly doesn't fix the other three uses.  (I tried using relativize
[not resolve], but failed to find any combination of parameters that
worked.)

Sam

On Jan 21, 2008 9:58 PM, Sam Berlin <sberlin@gmail.com> wrote:
> 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.
>
> Sam
>
>
> 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
> > >
> > >
> >
>

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


Mime
View raw message